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Computer activity at Manchester University 
began in 1 946 with the construction of a 
CRT-based memory, which was followed by a 
series of prototype computers. The work 
culminated in the Ferranti Mark I, completed in 
early 1951. This paper describes the 
programming systems devised, first for the 
prototype and then for the production Mark I, 
and includes an account of two novel automatic 
coding schemes developed during 1952 and 1954. 
The paper concludes with an assessment of the 
programming activity. 
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1 Introduction 

By 1950, there were three influential centers of 
programming in Britain where working com- 
puters had been constructed: Cambridge Univer- 
sity (the EDSAC). Manchester University (the 
Mark 1), and the National Physical Laboratory at 
Teddington (the Pilot ACE). At each of these cen- 
ters. distinctive styles of programming evolved, 
largely independently of each other. Through the 
activities of these centers and their commercially 
produced derivative machines (the LEO. the 
Ferranti Mark 1. and the DEUCE, respectively), 
the foundations of programming were laid in 
Britain during the early 1950s. Other influences 
were at work, of course, such as A. D. Booth’s 
work at Birkbeck College of London University 
that led to the successful HEC series of computers 
(Booth 1975); there were also numerous con- 
temporary developments in the United States. 
But none of these had nearly as much influence 
on programming in Britain as the three leading 
British centers at Cambridge, Manchester, and 
Teddington, where many early British pro- 
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grammers were initiated by means of program- 
ming schools, research studentships, second- 
ments. and industrial collaboration. 

This paper looks in detail at the early develop- 
ment of programming at Manchester University. 
Early programming activity at Cambridge Uni- 
versity was described in a companion paper 
(Campbell-Kelly, Annals of the History of Computing, 
Vol. 2, No. 1, January 1980), and programmingat 
the National Physical Laboratory is the subject of 
a third paper, in preparation. 

Early programming at Manchester centered on 
the Mark I computers, which was the name 
ascribed both to the prototype machines built at 
the university and to the commercially produced 
Ferranti Mark I, which spanned an era from 195 1 
until 1958. Key dates include the following: 

June 1948: “baby machine" first worked 
April 1949 to about August 1950: Mark I pro- 
totypes in use 

February 1951: Ferranti Mark I installed at 
Manchester University 

December 1958: maintenance discontinued on 
Ferranti Mark I 

The first part of this paper describes the early 
programming systems developed at Manchester; 
Section 2 describes the programming schemes 
devised by A. M. Turing for the prototype Mark 
I (in late 1949) and the production Mark I (in 
early 1951); Section 3 illustrates the program- 
ming system for the engineered Mark I by outlin- 
ing the preparation of a complete programming 
example. Partly because of the inadequacies of 
the programming system, very early work on 
automatic coding was done during 1952-1955 at 
Manchester, and Section 4 describes this. Finally, 
Section 5 gives an assessment of the whole pro- 
gramming activity. 

Terminology 

Perhaps a note on terminology is appropriate at 
this point. In general, contemporary terminology 
will be used, partly to evoke the period described, 
and pardy to avoid the risk of creating a false 
impression by the use of a modern term. (For 
example, the old term input routine will be used 
rather than loader or assembler-, indeed, neither of 
these would be quite appropriate because an in- 
put routine fell somewhere between the two.) I 
have also elected to retain the early British spell- 
ing programme and the hyphen in sub-routine, again 
to be in keeping with the period (and with per- 
haps just a little chauvinism). 
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131 1.1 Background' 

In July 1946, M. H. A. Newman, F.R.S., recently 
appointed Fielden Professor of Pure Mathematics 
at the University of Manchester, had obtained a 
Royal Society grant for a projected Computing 
Machine Laboratory. Newman was a member of 
the selection committee that appointed F. C. 
Williams to the Chair of Electro-technics; at the 
time of his appointment Williams was actively 
working on a novel digital store using cathode ray 
tubes. 

Williams continued this work when he took 
office at the University in December 1946, and he 
brought in an assistant, T. Kilburn. During 1947 
the Williams tube store, as it came to be known, 
was developed to a point where it could satisfac- 
torily store 2048 bits on a single CRT. The store 
was incorporated in a minimal computer in order 
to establish its viability: the “baby machine” began 
operation in June 1948 and was the first elec- 
tronic stored-program computer to be completed. 
With only 32 words of store, however, it was not 
capable of solving realistic problems. 

The baby machine was extended by a series of 
modifications to a state where it was capable of 
doing useful work by April 1949. when .it had 
become equipped with 128 words of Williams 
tube storage supplemented by a magnetic drum. 
By October 1949, the machine had received 
further improvements, including paper-tape in- 
put and output, and was used on a fairly regular 
basis for the solution of problems in various fields. 
This machine was shut down in August 1950. 

In November 1948, a contract had been placed 
with Ferranti Limited, a Manchester-based manu- 
facturer of electrical and electronic equipment, 
for the construction of the Mark I. The logic de- 
sign was completed late in 1949 and the machine 
was available from February 1951. Incidentally, 
there was some confusion over the name of the 
production Mark I in the early literature, where it 
was variously called MADM, Manchester Elec- 
tronic Computer Mark II, Ferranti Mark I, 
M.U.D.C., and M.U.E.D.C. In this paper, the 
computer is called the “Mark I,” which was what 
contemporary users called it. (The prototype ma- 
. chine was also called the Mark I, of course, but it 
should be clear in this account which machine is 
being referred to; the qualifiers “production” or 
“prototype” will be used where necessary.) 

Annals of 

the History of ' 

Computing 1 Background material has been obtained from a number of x 
Vol. 2. No. 2 publications on the history of Manchester computers: Laving- 
April 1980 ton (1975), Computer Weekly (1969), Williams (1975). 


After an inaugural conference for the produc- 
tion Mark I injuly 1951, the Computing Machine 
Laboratory became a thriving center of comput- 
ing in the north of England and began to attract 
many regular users from both within the univer- 
sity and outside. During 1952, the laboratory 
acquired a small but very competent staff who 
provided consultation, programming advice, and 
instruction. The impact of the laboratorv within 
the university was considerable and it attracted 
much interest from the science and engineering 
departments. By 1953, some 50 people had been 
trained to use the machine. Outside users in- 
cluded representatives from industry, govern- 
ment establishments, and research organizations; 
the programming group within Ferranti had par- 
ticularly close links with the laboratory. Many of 
these early users are now significant names in the 
British computer community. 

Ferranti sold a second Mark I to the University 
of Toronto and produced a follow-up machine 
with a slightly rationalized order code, the Mark 
I*, of which seven were sold. The collaboration 
between the university and Ferranti was excep- 
tionally fruitful; Ferranti marketed two further 
machines, the Mercurv and Atlas, based on Man- 
chester University designs, before disposing of 
their computer interests in 1 963. A Mercurv- com- 
puter was installed in the laboratory in October 
1957, and over the next year the Mark I gradually 
went out of use; it was dismantled in June 1959. 

Manchester University has long been rec- 
ognized as one of the w-orld’s leading centers of 
hardware innovation, arguably reaching a peak 
with the virtual memory of the Atlas computer. 
There have also been some notable software suc- 
cesses, especially the compiler-compiler (Brooker 
et al. 1964) and the Adas Supervisor (Kilburn et 
al. 1961). Manchester has also played a leading 
role in computer education, having instituted 
the first university undergraduate course in 
computer science in Britain in 1965. Through its 
graduate and postgraduate students, as well as its 
wealth of technical innovation and industrial col- 
laboration, Manchester University continues to 
play a major role in the British computer scene. 

1.2 People 

The two principal people in early computer 
development at Manchester University were 
M. H. A. Newman and F. C. Williams. Newman 
had a considerable reputation as a pure mathema- 
tician, gained before the war, and he had spent 
the war years engaged on cryptography at Blelch- 
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132 ley Park where he had been associated with the the prototype and production machines and in 

development of special-purpose electronic code- running very early programmes in number 
I t P t UterS ( Rande11 1976) \ His mfluence theory. Subsequently, Turing was responsible for 
h ■ • 1 B r P ro J ect was very important: in the early programming systems. Turing’s contri- 
obtainmg Royal Society funds, in his enthusiasm butions to computing are well known- foe classic 
for and encouragement of the project, and in “Turing machine” work before the war work on 
thi P ma S chine PeClfy ^ funCt ‘° nal rec l u ' rem ents of code-breaking machinery during the war, and the 
war u . - , , logic d “ign of the ACE computer in 1945 

W illiams had a background as an extraordi- (Carpenter and Doran 1977). Sadly Turing’s pro 

S Tq 78 1V H’ CtnC engmeer (KiIbUrn and §“§ developments for the Mark i didZ 
P g °i ^ yean Were Spent on radar match these earl y achievements and were not an 

work at telecommunications Research Estab- example of his finest work. Turing's interest in 
is ment ( ERE). CR T storage was originally con- computer development declined during 1951 as 
ceived in connection with storing radar data for his interests turned toward morphogenesis al- 
ec o cancellation. Developing this basic concept though he remained a heavy user o § f machine 

time - H e was elected to the Royal Society in 1951 

„ In 0ctober I949 ' Cicely Popplewell joined the 
Martm Lampbell-Kelly is Senior Lecturer in ihe Computing Machine Laboratory as Turing’s pro- 

Department of Mathematics and Computer Studies, gramming assistant. Popplewell had a back- 
Simde-rlard Polytechnic, England. He is a graduate ground of computing using a punched-card 
oj the Department of Computer Science, University of installation, and the terms of her appointment 
Manchester. were that she would assist in the preparation of a 

library of sub-routines for the prototype Mark I. 

• , ■ , , . ,. . , Audrey Bates, an M.Sc. research student suDer- 

int°. a workable digital store was an outstanding vised by Turing, arrived a litde later The only 
engineering achievement. Williams’s work on other regular user of the prototype Marklwas 
computers was a relatively short span of a long D. G. Prmz of Ferranti, who used foe machine for 
career as an electrical engineer, and his finest engineering calculations. 

achievements he in that field. He was the recipient In mid- 195 1 , with the installation of the pro- 
- ad ^‘c honors, was elected to the duction Mark I, the Computing Machine Labora- 

a year before his death W3S § ” 19?6 ’ ^ be § an to attract man V ou ^e users. The first 

wir u , . ' ..... of these were A. E. Glennie and K. N. Dodd of the j 

th)\w? S brought r - 1 ^ 1 i!E )urn to assist him in Armaments Research Establishment They had 
e elopment of the CRT store. Kilburn had both formerly worked on EDSAC and brought 
graduated in mathematics at Cambridge L mver- with them something of the Cambridge approach 
sity in 1942 and spent the remaining war years to programming. Glennie spent about 60% P o f his 
working under Williams oh radar and other de- time at Manchester until the end of 1954 and 
ve opments at ERE. In 1952, Kilburn assumed made very interesting contributions to pro 
foil responsibility for computer developments at gramming system development in particuWan 
Manchester Umversity, when Williams’s inter- early compiler. P P an 

with^ U \fm-k °^ her ^ hil j(s s - Iviiburn’s involvement R. A. Brooker, who had also worked with 
with Mark I was mainly on engineering and EDSAC, was appointed to the staff of the labo 

C ZSi ,S r he T",uVr dby rator y in October 1951 to strengthen the 
and C F Thom ,T°° ’ fT- Rot L mson ’ programming effort. Brooker, assisted by Pop- 

and G E. Thomas all now leading British plewell, was responsible for programming system 
compu^r scientists. Kilburn’s contributions to development frem this time P aSnTthe dutfos 
computer engineermg and design have been rec- that no F longer interested Turing. Brooker’s mos 
T Zed by numerous academ.c honors; he was notable achievement was a highly successful auto 

In lent mber° y i a 94 S 8 OC1 A y M T’ system, Ve Marti W 

in September 1948 A. M. Turing was ap- code. Brooker remained at Manchester for manv 

pointed Reader m the Department of Mathemat- years, where his considerable achievements in- 

So, would n tadtheTa;h V ^ ^ duded the MerCU ^ Autocode (Brooker 1 958) 

Computing ^?"' d r " athemauca l s * de of the work’ and the compiler-compiler. Since 1967, Brooker 

AminaSci 2 U I 1 . 95 ^ ) ’. Newman and Turing were both has held the Chair of Computer Science at Essex 
Apni i960 closely involved in specifying the requirements of University. tssex 
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133 One visitor to the laboratory of particular inter- 

est was C. Strachey. Both Brooker and Popple- 
w-ell relate an anecdote about their first meeting 
with him. Strachey, then a master at Harrow 
School, had obtained a copy of the Mark I pro- 
grammer’s handbook. He wrote a programme to 
play draughts (checkers) and asked if he could 
visit the laboratory the following half-term holi- 
day to run it. (This would be October or No- 
vember 1951.) Permission was given and Strachey 
sent his programme for punching beforehand. 
The programme was about 20 pages long (over a 
thousand instructions) and the naivete of a 
first-time user attempting a programme of such 
a length caused not a little amusement among the 
programmers in the laboratory. Anyway, the day 
came and Strachey loaded his .programme into 
the Mark I. After a couple of errors were fixed, 
the programme ran straight through and finished 
by playing “God Save the King” on the “hooter” 
(loudspeaker). On that day Strachey acquired a 
formidable reputation as a programmer that, he 
never lost. Soon after, Strachey was hired as a 
consultant by the National Research and Develop- 
ment Corporation at a salary that Harrow School 
could not match. One of his first jobs was as a 
consultant on calculations for the St. Lawrence 
seaway project using the Ferranti Mark I at the 
University of Toronto. 

Two early users of the Mark I, starting in mid- 
1951, were N. E. Hoskin, assistant lecturer, and 
R. K. Livesley, research student, in the Depart- 
ment of Mathematics. In August 1952 they took 
the first two research assistantships in program- 
ming in the laboratory. Working under Brooker, 
they advised outside users and assisted in the 
development of the sub-routine library. Other 
contributors to the programming activity in- 
cluded D. C. Gilles, B. Richards, F. H. Sumner, 
and D. Morris, all currently professors of com- 
puter science in Britain — the latter two in the 
present Department of Computer Science at 
Manchester. 

1.3 Sources 

In addition to the open literature (see references) 
a number of less accessible sources have been 
used in preparing this paper. 

There is very litde programming documenta- 
uon for the prototype Mark I. G. C. Toodll kept, 
a notebook (1948-1949) during his period at the 
Annals of university; it contains many fascinating notes on 
Computing °' ^ develo P m ent of the prototype machine, but 
vot 2 . No 2 few on programming. The papers of D. G. Prinz, 
April 1980 who was actively involved in programming, con- 


tain some interesting fragments but little of 
substance. Audrey Bates’s thesis (1950) contains 
listings of her programmes for symbolic logic, but 
there is little discussion of the programming 
system as such. Probably the fullest account of 
programming for the prototype machine is con- 
tained in an appendix to the first programmer’s 
handbook for the production Mark I (HB1). 
Cicely Popplewell wrote an account of her pro- 
gramming experience with the prototy pe Mark I 
in 1969; the material is anecdotal rather than 
technical (Popplewell 1969a, 6). \ 

A beautifully printed proceedings of foe Inau- 
gural Conference of foe production Mark I in 
July 195 1 contains a number of interesting papers 
and discussions on programming (Manchester 

1951) . (Incidentally, the proceedings contains a 
list of the 169 conference delegates; this includes 
just about everybody in Britain who had an inter- 
est in computers at the time.) The various pro- 
gramming systems for the Mark I were well 
documented in a series of programmer’s hand- 
books issued from 1951 to 1956. The first 
handbook was written by T uring (HB 1); as well as 
an appreciable number of errors, it contains some 
fine examples of his delightful prose, of which the 
following may serve as a specimen; “The engi- 
neers . . . will consider the removal of a valve or 
the connection of two points temporarily with 
crocodile clips to be admissible but would frown 
on certain users of a hatchet.” 

Turing’s manual was not a model of clarity, and 
Prinz wrote a simplified handbook for internal 
use by Ferranti’s programming group (Prinz 

1952) . Brooker produced a revised handbook in 
August 1952 (HB2) that was duller but more 
reliable than Turing’s. This was followed by a 
supplement of examples (HB2S) a few months 
later. A third handbook (HB3) was issued in Sep- 
tember 1953 and a supplement to this (HB3S) in 
January 1956. Most of the handbooks are at pres- 
ent in private hands. In addition to foe hand- 
books, there was a fair amount of documentation 
of programmes and sub-routine specifications on 
loose sheets; much of this has been lost, although 
there is a good deal of early material in foe papers 
of the late C. Strachey. 2 

The Strachey papers contain many items relat- 
ing to the Mark I, such as the original draughts 
programme (all written out on the “prep sheets” 
of Harrow scholars!). Strachey used foe CRT 
monitor tube to display the draughts board, and 

2 Now being cataloged by the Contemporary Scientific Ar- 
chives Centre, Oxford. 
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134 there are photographs of this. There is also a pro- 

gramme for writing love letters and a good deal of 
material on Strachey's consultancy work on the 
second Ferranti Mark 1. the FERUT, at the Uni- 
versity of Toronto. 

Glennie and Brooker have both retained work- 
ing papers for their autocodes, and 1 drew on 
these extensively for Section 4 of this paper. Con- 
versations with Kilburn. Brooker, Glennie, 
Popplewell, and Prinz have added substantially to 
the content of this report. Finally, several early 
users have provided me with written answers to 
questions. 

2 Early Programming System Development 

This section describes the programming svstems 
devised by Turing for the prototype Mark I dur- 
ing 1949 and for the production Mark I in 1951. 
Two further but essentiallv similar programming 
schemes devised during 1952-1953 are also de- 
scribed. All the programming systems were based 
on a simple input routine and a sub-routine li- 
brary. Before going into programming details, we 
will discuss the Mark I and its instruction code. 

2.1 The Mark I 

The history of the Mark I is complicated by the 
fact that there was an evolutionary process from 
the first experimental machine through to the 
production Mark I. To some extent, the evolu- 
tionary process was continuous, but from the pro- 
grammer’s point of view four distinct machines 
can be identified: the baby machine, two proto- 
type versions of the Mark I (called the “improved 
machine" and the “large-scale machine” by 
Williams and Kilburn at the Inaugural Confer- 
ence in July 1951. although in fact most of the 
hardware was common and there was little differ- 
ence in size), and the production Mark I. A sum- 
mary of this evolution is: 

June 1948: baby machine working 
April 1949: improved machine available 
October 1949: large-scale machine available 
February 1951: production Mark I available 

2.1.1 The baby machine. A small-scale experi- 
mental computer known as the miniature or baby 
machine first operated successfully on June 21, 
1948, and was the first EDVAC-type electronic 
stored-program computer to be completed. The 
logic design was by Kilburn (mainly) and Wil- 
liams; the object of building the machine was to 
demonstrate the suitability of Williams tube stor- 
age for digital computers. 
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address function spare 

( a ) Baby machine 


10 14 5 

address B-line spare function 
(. b ) Prototype Mark I 


10 3 16 

address B-line spare function 

(c) Mark I 

Figure 1. Evolution of the instruction format. 


The miniature machine is described in consid- 
erable detail in Williams et al. (1951). It had 32 
words of Williams tube storage and an order code 
of seven instructions. Figure la shows the instruc- 
tion format. Binary programmes were put, bit by 
bit, into the store using manual keys and a "type- 
writer” of 32 pushbuttons, each button corre- 
sponding to one bit of the store line. “Output” was 
obtained by inspection of the Williams tube moni- 
tor. Williams (1975, p. 330) evocatively described 
the operation of the first programme to be run: 

When first built, a program was laboriously 

inserted and the start switch pressed. Immediately i 

the spots on the display tube entered a mad dance. 

In early trials it was a dance of death leading to no 
useful result, and what was even worse, without 
yielding any clue as to what was wrong. But one 
day it stopped and there, shining brightly in the 
expected place, was the expected answer. It was a 
moment to remember. 

The programme referred to was a 17-in- 
struction routine to compute the highest factor of 
an integer. 3 Subsequently, this programme ran 
for 52 minutes, doing over 3.5 million operations, 
to compute the highest factor of 2 18 ; the duration 
of this run amply confirmed the suitability of 
Williams tube storage. Now the emphasis shifted 
toward constructing a more ambitious machine. 


3 The original programme has been lost, but there is a later 
version (Julv 1948) in Toottll’s notebook and another 
(November 1948) in Prinz's papers. 


Manchester Mark t • M. Campbeil-Kelly 


135 


Annals ol 
the History of 
Computing 
Vol. 2, No. 2 
April 1980 


2.1.2 The improved machine. Several enhance- 
ments were made to the baby machine, and the 
improved machine was doing useful work from 
April 1949. The word length was increased from 
32 to 40 bits to reduce rounding errors. This 
turned out to be a fortunate choice for it made 
double-length working at Manchester largely un- 
necessary. The 40-bit word could also accom- 
modate two 20-bit instructions, as in Figure 16. 
The CRT storage capacity was increased to 128 
words, supplemented by a 1024-word magnetic 
drum. At this stage transfers between the mag- 
netic and electrostatic store could only be 
achieved with manual intervention to set appro- 
priate switches. 

The order code now consisted of 26 instruc- 
tions, including orders for setting the B-lines. In 
retrospect, the most enduring contribution of the 
Mark I was the concept of B-lines, which are now 
embodied as index registers in all computers. The 
reason for the term B-line was that A and C had 
already been used for the accumulator and con- 
trol: presumably the multiplicand register be- 
came known as the D-register for a similar reason. 

The B-line patent is in the names of Newman, 
Williams, Kilburn, and Tootill. It was probably a 
collective rather than an individual invention, al- 
though the memories of the participants are not 
in complete accord as to the actual events. The 
key features offered by the B-line were: 

1. The ability to add a preset word to an in- 
struction before obeying it (i.e., indexed 
addressing). 

2. The provision of extra central registers in 
addition to the accumulator. 

3. The ability to relocate a sub-routine (i.e., use 
as a base register). 

In practice, the third feature— use as a relocation 
register — was not particularly effective and was 
never exploited. 

Input and output for the improved machine 
used the same arrangements as the baby machine: 
a panel of pushbuttons for input and output by 
inspection of the Williams tube monitor. Because 
of the primitive input/output, there was no pro- 
gramming system or sub-routine library, of 
course; programmes were coded in binary and 
inserted one digit at a time. Even so, useful work 
was done on the investigation of Mersenne primes 
in June 1949 and was announced by Newman in 
a letter to the Times (1949a) and reported at the 
Cambridge University Computer Conference the 
same month (Newman 19496). Kilburn and 


Tootill wrote the original programme, which was 
subsequently improved by Turing (Lavington 
1975, p. 12). 

2.1.3 The large-scale machine. During the sum- 
mer of 1949 work began on the extension of the 
improved machine and was completed by the fol- 
lowing October. The main enhancements con- 
sisted of instructions for programmed drum 
transfers and the provision of input/output using 
standard teleprinter equipment. 'The teleprinter 
equipment was acquired hy Turing through con- 
tacts with the Foreign Office Department of Com- 
munications at Bletchley Park and installed in 
June or July. The equipment include a keyboard 
perforator of German origin (“liberated” during 
the war) with a “considerable tendency to replace 
the digit 1 by 0” (HB1, p. 92). 

At this time the electrostatic storage was ex- 
tremely sensitive to electric interference of any 
kind and for this reason, as well as lack of space, 
the magnetic drum and teleprinter equipment 
were housed in a room on the floor above. The 
terms up and down transfers persisted for years 
afterward. 

With the addition of the teleprinter input/ 
output equipment, Turing was able to develop a 
programming system that superseded the former 
method of entering programmes in binary by 
means of the panel of pushbuttons. When 
Popplewell arrived in October 1949 the pro- 
gramming system had just come into use; some 
years later she wrote her recollections of pro- 
gramming the prototype machine (1969a): 

Operating the machine required considerable 
physical stamina. Starting in the machine room one 
alerted the engineer and then used the hand 
switches to bring down and enter the input 
program. A bright band on the monitor tube 
indicated that the waiting loop had been entered. 
When this had been achieved, one ran upstairs and 
put the tape in the tape reader and then returned 
to the machine room. If the machine was still 
obeying the input loop one called to the engineer 
to switch on the writing current, and cleared the 
accumulator (allowing the control to emerge from 
the loop). With luck, the tape was read. As soon as 
the pattern on the monitor showed that input was 
ended the engineer switched off the write current 
to the drum. Programs which wrote to the drum 
during the execution phase were considered very 
daring. As every vehicle that drove past was a 
potential source of spurious digits, it usually took 
many attempts to get a tape in — each attempt 
needing another trip up to the tape room. 
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A small library ot sub-routines was developed 
for the prototype and a small number of full-scale 
problems tackled. The latter included work by 
Turing on Mersenne primes and the Rtemann 
hypothesis; Popplewell did work on rav tracing, 
Bates did work on symbolic logic for her Master’s 
thesis, and Prinz did work on Laguerre functions 
for an engineering application at Ferranti. 1 The 
prototype was closed down about August 1950, 
pending the arrival of the production model. 

2.1 A The Ferranti Mark I. During the summer 
of 1949, work on the production Mark I had 
started at Ferranti. Working to the requirements 
of Newman and Turing, Tootill developed the 
logic design at Ferranti from August to No- 
vember 1949. The computer was installed at Man- 
chester University for final testing in February 
1951 and was used for programming systems and 
other development work until it was officially 
inaugurated in July 1951. 

The Mark I, although a fairly conventional 
single-address machine, had many interesting 
features of which only a few can be described 
here. The instruction format, given in Figure lr, 
was essentially the same as on the prototype, with 
the operation code field extended to six bits and 
three bits now used to specify one of eight B-lines. 
The ten-bit address accommodated an address 
space of 1024 lines of electrostatic storage, al- 
though only 512 lines were actually provided. In- 
cidentally, line is almost alw ays used in preference 
to word in the Mark I literature; a long line was 40 
bits, a short line 20 bits, and a line usually meant 
a short line. Of course, a line had a physical ana- 
log in the form of the trace on the Williams tube. 

Notice that the instruction is in the reverse 
direction to how we conventionally write instruc- 
tion formats — the least significant digit of the 
address is on the left. The same was true for 
numbers, which were written with the least 
significant digit on the left and the most sig- 
nificant on the right. The reason for this is that in 
a serial machine, the digits are produced least- 
significant digit first; Williams tubes and oscillo- 
scopes conventionally sweep with time going from 
left to right, so it was natural to write binary 
numbers that way and this was common on early 
computers. 

The instruction repertoire had been extended 
to 50 orders and the additional orders included 

1 The output from Prinz's programme is still in existence, 
dated August 1950. 


instructions for B-line arithmetic, arithmetic in- 
structions for both signed and unsigned fractions, 
and a number of miscellaneous instructions. In- 
struction times were on the order of 1 ms. 

Instruction modification in the Mark I is partic- 
ularly interesting. Unlike present-day machines, 
the B-line of 20 bits modified the entire instruc- 
tion and not just the address field. This could 
result in a change of operation code and/or B-line 
when the instruction was modified. Some very 
curious tricks could be, and were, programmed 
by this means. 

Although only 50 of the 64 possible operation 
orders were defined, decoder minimization was 
used so that in fact every order did do something. 
The convention that programmers would not use 
undefined orders was generally followed. 

Transfer-of-control instructions were interest- 
ing from a systems programmer's point of view. 
The address part of a branch instruction was not 
the destination of the branch, but instead the ad- 
dress of a line containing that destination. This 
made things such as jump tables very easy to im- 
plement and the forward-reference problem 
nonexistent. There were both absolute and rela- 
tive versions of branch instructions; the latter 
were particularly useful for writing position- 
independent code. 

There were no shift orders, shifts being 
achieved by multiplication by powers of two. The 
high-speed multiplier was much faster than, and 
eliminated the need for, a shift unit although it 
did mean that about 40 lines of store were perma- 
nently occupied by powers of two. (Limited shift- 
ing could, however, be achieved by an order that 
doubled the contents of the accumulator.) 

At the request of Turing an instruction to gen- 
erate a random number from a noise source was 
provided. Unfortunately, the numbers turned 
out to be not particularly random, and debugging 
was difficult because programmes were not re- 
peatable: consequently, the instruction eventually 
fell into disuse. There is a story that a gambling 
programme counted the number of times the 
digits 0, 1. .... 9 were produced by the random- 
number generator. F. C. Williams would encour- 
age unsuspecting visitors to play this game 
(Livesley 1979); he always adjusted the generator 
beforehand to produce more Is than 0s and then 
put his money on 7! 

Other curious instructions included a sideways 
add that gave the number of binary Is in a word 
(requested by Newman for problems in number 
theory) and a “hoot” instruction that pulsed a 
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Obey H as magnetic instruction 

S’ = M 

Normalize 

S' = M, A' = L+ 

Obey S as magnetic instruction 
S' = L 

L' = M, M' = L 

S' = L, L' = M, M' = 0 

A' = A - DS + 

A' = A - DS ± 

Sideways add 
M' = M + S 
A' = A + DS+ 

A' = A + DS-. 

D' = S + 

D' = S s 

B-conditional absolute transter 
S' = H 
Optional stop 
Random number 
A-conditional absolute transfer 
S' = clock 

Unconditional absolute transfer 
Unconditional relative transfer 
B-conditional relative transfer 

Optional stop 

A-conditional absolute transfer 


Mark I instruction set 


L' = S + , M' = 0 
L' = S' = S v L 
L' = 65th line 
S' = L, A' = 0 
A' = 0 

S’ = L' = Svl_ A = 0 
A' = A + S + 


’ S» (logical OR) 

1 Sj, (logical AND.) 

4 S» (logical EXCLUSIVE OR) 

- S* 


B' = S 
3' = B 
3' = B - S 


unmodified 


Instructions are defined by equations in a notation by Turing 
The following symbols are used: 

A = accumulator 
L = lower accumulator 
M = upper accumulator 
D = multiplicand register 
8 = 8-line 
S = store line 
H = hand switches 
± = suffix meaning signed fraction 
+ = suffix meaning positive fraction, no suffix means 
signed integer 

= suffix meaning value after operation, unprimed means 
value before operation 


T£ No operation 

„ Absolute transfers of control go to line n+1 where r> is the 
control number” in the line addressed by the instruction. 
Relative transfers skip n instructions. ''A-conditional" means 
"if the accumulator > 0" and ”8-conditionar means "if the last 
B-line altered s 0.” 

Drum and input/output transfers were specified by a control 
word (or "magnetic instruction”) in the store line addressed by 
the instruction. The format of this control word has been 
omitted for brevity. 

The usual instructions for setting and performing arithmetic 
on B-lines were TO, TB, and TG, which were not modified. 
Occasionally, if modification was required, TT, TZ. and TL 
were used; these were mainly used for subtle programming 
tricks. 
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loudspeaker. Another instruction gave the posi- 
tion of the most significant 1 in a word; this was 
useful for normalizing floating-point numbers. 
Abbreviated instruction codes for the Mark I are 
given in Table 1. This table is not intended to be 
fully self-explanatory, but it should enable the 
programmes given in this paper to be under- 


stood. (The peculiar operation codes //, /E, etc., 
will be explained later.) 

Peripherals for the Mark I were a high-speed 
paper-tape reader for input (about 150 characters 
per second) and a teleprinter and paper-tape 
punch for output (6% and 15 characters per 
second, respectively). 
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138 Peripheral and drum transfers were pro- 

grammed by a control word known as a “magnetic 
instruction” or an “auxiliary instruction.” It was 
possible to verify magnetic transfers using special 
checking instructions provided because of the 
difficulties experienced on the prototype. Read- 
ing, writing, and checking operations took 30, 90, 
and 45 ms, respectively. 

The electronic store was divided into “pages” of 
64 lines and each track of the drum held two 
pages. Transfers between the electronic and 
magnetic stores always consisted of one or two 
whole pages. The nature of this “two-level” store 
affected programming more than any other fea- 
tures of the Mark I. 

A 65th line associated with each 64-line page of 
electronic store contained the number of the track 
on the drum from which the page had been read. 
By accessing the 65th line it was possible to asso- 
ciate each page in the electronic store with the 
track on the drum from which it originated. 
Kilburn (1979) recalls providing this as a facility 
that might prove useful to programmers; it was 
the germ of an idea that later led to the virtual 
store of the Atlas computer. Sadly, it was not ef- 
fectively exploited by programmers during the 
life of the machine, although the engineers found 
it useful in test programmes for the drum. 

Like most early machines, the Mark I was not 
particularly reliable. The worst problem initially 
was the magnetic drum, which turned out to have 
too high a packing density so that some 40% of 
tracks were inoperative at some point in their life. 
Much of a programmer's time was spent arrang- 
ing programmes onto those tracks performing 
satisfactorily in a particular session. This problem 
was much alleviated in 1953 when the original 
6-inch drum was replaced by one 10 inches in 
diameter. Similarly, the electronic store was prone 
to "clodding" by which it picked up spurious 
digits. It was recommended that the store should 
not be relied on for more than about 2 minutes of 
error-free operation. Thus, quite a lot of effort 
went into making programmes that could be re- 
started and in which checks were made on the 
validity of numerical results. 

2.2 Programme Organisation 
The two-level store of the Mark I gave rise to a 
method of programme organization and use of 
Annals ot storage very characterisuc of the Manchester 
Computing sch ° o1 - Vesti g es of this can be seen in subsequent 
Voi. 2. No. 2 Manchester computers, especially in the paged 
April 1980 store of the Atlas. 


The programming scheme for the prototype 
Mark I was devised by Turing and he subse- 
quently adapted it to the production model. At 
the outset a number of arrangements must have 
seemed possible, but the scheme wherein a pro- 
gramme was broken into pages was a most effec- 
tive way of using the machine. Certainly, it was 
much neater than the overlaying techniques 
generally used when disk stores became available 
in the early 1960s. 

The two levels of storage on the Mark I — 
magnetic and electronic — constituted a substan- 
tial direct-access store and a much smaller 
immediate-access store, respectively. Turing had 
a neat analogy for this (HB1, p. 4): 

It is as if information in the magnetic store were 
written in a book. In order to find any required 
piece of information it is necessary to open the 
book at the required page — The electronic store 
... is to be compared rather to a number of sheets 
of paper exposed to the light on a table, so that 
any particular word or symbol becomes visible as 
soon as the eye focusses on it. 

The analogy with books and pages is carried to 
great lengths and the terms chapter, page, column, 
paragraph, and line were all used. 

Figure 2 a shows the storage layout of the proto- 
type Mark I. The electronic store of 128 forty-bit 
lines was held on four Williams tubes. The mem- 
ory was divided into four pages of 32 lines, one 
page per Williams tube. The pages were further 
subdivided into upper and lower paragraphs of 
1 6 long lines or 32 short lines. (The significance of 
grouping into 32 short lines will become clear in 
the next section.) A programme was coded as a 
series of independent pages or chapters (two 
pages) that were brought down in turn from the 
drum to the first two pages for execution. The 
third page was used for “systematic working 
space" (i.e., vectors) and the upper paragraph of 
the fourth page was used for “unsystematic work- 
ing space” (i.e., variables). Finally, the lower 
paragraph of the fourth page contained a perma- 
nently resident block of code. PERM contained 
useful constants and a sequence of instructions 
for bringing down a routine from drum; PERM 
was the heart of the programming system and 
had much in common with the resident monitors 
of later machines. 

The physical separation of a programme’s in- 
structions and data was done for quite different 
reasons than in today's reentrant code. It was 
done on the Mark I because a programme was 
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unsystematic 

working 

space 



routine(s) systematic PERM 
working 
space 

(a) Prototype Mark I (details taken from HB1 appendix) 


page: SO 

I 

column: / E 


S2 S3 


S5 S6 


SIUV5>DRJNFCK 



routine(s) 


Figure 2. Storage organization. 


systematic 

working 

space 


unsystematic PERM 
working 
space 


(b) Mark I 


coded as a series of pages that constantly overlaid 
one another; hence, working storage had to be 
kept separately. 

The storage organization on the production 
Mark I was essentially similar to the prototype. At 
first 16 pages of electronic store on 16 Williams 
tubes was planned, but in the end only eight tubes 
were provided, as shown in Figure 2b. The eight 

pages were designated SO, SI S7. Each page 

was divided into two columns and the columns 

were “numbered” /, E, @ K (for reasons that 

will become clear shordy). The division of a page 
into two columns, rather than two paragraphs as 
Annals of on the prototype, reflected the fact that lines were 
Computing stored column by column instead of row by row. 
voi. 2. No 2 Because of the uncertainty of the eventual size of 
April 1980 the electronic store, Turing organized storage as- 


suming five pages, which he regarded as the mini- 
mum workable store. This is shown in Figure 2b. 
The remaining pages, S3, 5, and 6, were allocated 
for additional working space at the discretion of 
the user. Of course, the designation of storage in 
this way was purely a convention, and these con- 
venuons “should not be regarded as pure tyr- 
anny, but to know that they have been obeyed in 
the programmes one is using is a great comfort” 
(HBl.p. 48). 

23 The Written Form of Programmes 
In October 1948, at Tootill’s instigation, the prac- 
tice was adopted of using five-bit teleprinter codes 
to represent binary numbers when reading 
aloud from the monitor tube so that a second 
person could write them down (Tootill 1978). Ta- 
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Table 2. 

Teleprinter codes 


Decimal 

Symool 

Binary 

0 


oocco 

1 

P 

10000 

2 

ft a l 

01 COO 

3 

A 

11000 

4 


00100 

5 

s 

10100 

6 

1 

01100 

7 

u 

11100 

8 

Yz- 

00010 

9 

n 

10010 

10 

R 

01010 

11 

J 

11010 

12 

N 

00110 

13 

F 

10110 

14 

c 

omo 

15 

K 

11110 

16 

~ 

00001 

17 

Z 

10001 

18 

L 

01001 

19 

w 

11001 

20 

H 

00101 

21 

y 

10101 

22 

P 

01101 

23 

Q 

11101 

24 

0 

00011 

25 

3 

10011 

26 

8 

01011 

27 

" 

11011 

28 

M 

00111 

29 

X 

10111 

30 

V 

01111 

31 

i 

11111 


Annals of 
the History of 
Computing 
Vol. 2. No. 2 
Aoril 1980 


ble 2 shows the 32 characters in the teleprinter 
sequence. A binary number such as 

00000 01010 11100 10111 

would have been read as /RUX (/, the symbol for 
zero, was called “stroke"). Teleprinter codes were 
thereafter used to represent instructions as well. 
The use of teleprinter codes was established long 
before the installation of teleprinter equipment in 
the summer of 1949 and no doubt was a major 
factor in selecting this type of equipment. 

It was perhaps natural (though certainly 
unfortunate) that Turing should continue to use 
teleprinter notation in his programming systems 
for the Mark I, a notation Wilkes (1968) justly 
described as “bizarre in the extreme.” 

Because / was used for zero, it was the most 
commonly occurring symbol in the written form 
of instructions and gave Manchester programmes 


a characteristic look (see, for example, Figure 5 d). 
At Cambridge, S. Gill remarked (Brooker 1978) 
that Mark I programmes reflected the Man- 
chester weather, because a programme looked 
like rain seen through a dirty window pane! 

Turing advocated that programmers should 
begin bv learning the teleprinter sequence, which 
ran 

/E@A:SIL'! / 2DRJNFCKTZLWHYPQOBG ,, MXV£ 

This was easier said than done. Prinz, for one. was 
driven to devise the following mnemonic (which 
he remembers to this day):° 

stroke Edith at Aberdeen colon She Is Under half 

Dispense Royaljustice Napoleon For Charlie Knows 
Tall Zebras Laugh 

We Hear Young People Question On Best Grounds 

Quotations for a thousand fifteen pounds 

The teleprinter sequence thus was indelibly im- 
printed on the minds of all Mark l users (and 
those I have spoken to still remember it after a full 
20 years). There is a story (Prinz 1978) that 
Audrev Bates was once asked what letter followed 
K in the alphabet; she instinctively said T. 
(Mercifully, the teleprinter sequence was rear- 
ranged into alphabetical order for the Mark I* 
computers.) 

Each 20-bit instruction was written as a se- 
quence of four teleprinter characters. Referring 
to Figure 1. in the case of the prototype machine, 
two characters specified the address, one char- 
acter specified the B-line, and one character gave 
the operation. There was thus a natural division 
of the instruction into groups of 5 and 10 bits, 
each corresponding to one or two teleprinter 
characters. Unfortunately, in the case of the pro- 
duction Mark I, this natural division no longer 
obtained, because the operation code had been 
extended to six bits. Hence, the B-line and the 
operation code were represented by a pair of tele- 
printer characters. A particular operation was 
therefore not represented in the written form of 
programmes by a unique code; this made pro- 
gramme manuscripts particularly difficult to un- 
derstand. 

The written form of the address part of an in- 
struction looked curious. For example, the ad- 
dress H; would mean line H of column : (a store 
line was never referred to by its decimal address, 
line 148 in this case). In fact, because pages and 

3 Tootiirs notebook gives a mnemonic that predates Prinz’s, 
but it is not as cute. 
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141 columns were so intimately connected with the 

architecture of the machine, it was rarely neces- 
sary to know absolute addresses as such, but in- 
stead the line number within a column. 

Figure 3 shows a complete instruction for the 
Mark I. The instruction, written H:YA, stores the 
accumulator into line H: modified by B-line 5. In 
a modern assembly language this would probably 
be written in a form such as 

STA 148,5 

The written form of Mark I instructions no 
doubt looks distinctly odd to a modern pro- 
grammer. But there were some definite reasons 
for using teleprinter notation, as Turing ex- 
plained at the Inaugural Conference of July 1951. 
First, debugging at the console was made consid- 
erably easier by having a close correspondence 
between the written form of an instruction and 
the binary form in the machine. Second, the pro- 
grammer needed to be constantly aware of page 
boundaries, and this would not be nearly so ap- 
parent if a decimal address were used. Third, 
Turing argued, since the names of store lines and 
function codes were no more than arbitrary 
labels, it did not matter what they were called. 

2.4 The Input Routines 

An input routine was the term used in Britain for 
several years for a programme that read in other 
programmes. Input routines varied in sophistica- 
tion 3 from the very simplest form of loader at one 
extreme to systems approaching the complexity 
of a modern assembler at the other. The input 
routines for the Mark I were much closer to the 
former than the latter. 

The input routines for the Mark I were perma- 
nently stored on the drum on “isolated” tracks. 
(An isolated track was one to which writing had 
been disabled so that the track could not be acci- 
dentally overwritten.) The input routine was 
loaded into the electronic store by the following 
ingenious bootstrapping technique devised by 
Kilburn and Tootill (Tootill 1978). The electronic 
store arid control registers were cleared and the 
machine started. It thus obeyed the instruction in 
location zero, which itself consisted of all zeros 
(////). The instruction // caused the hand switches 
to be obeyed as a “magnetic instruction” (see 
Table 1). Hence, the track designated by the hand 
Annals of switches was brought into the electronic store and 
the History of control took the next instruction from location 1 , 

Computing w hich now contained the first instruction of the 
Vol. 2, No. 2 

April i960 input routine. 


00 1 0 1 0 o 1 0 o|l 0 1 |o| 1 1 1 000 



H Y A 


Figure 3. Specimen Mark I instruction. 

An input routine was placed on the drum in the 
first place, or replaced in case of accidental era- 
sure, by a simple bootstrap routine known as 
“initial input,” which copied a binary tape of the 
input routine onto the drum. The initial input 
routine was loaded manually by means of the 
hand switches. (A typical initial input is given in 
HB3, p. 4-14.) 

The input routine for the prototype Mark I was 
devised by Turing, assisted by D. B. G. Edwards 
and Tootill, who advised on hardware constraints 
(Kilburn 1978, Tootill 1978). So far as is known, 
no copy of the original input routine is extant, but 
a brief description of it is in the appendix of the 
first handbook. The input routine was probably 
first used in October 1949; Popplewell recalls that 
when she arrived in that month, it was working 
but only one sub-routine had been written (for 
reciprocal). 

The input routine was simple in the extreme. A 
user programme was punched onto tape as a 
series of instruction pairs. Each instruction pair 
was prefixed by a “warning character” and the 
address of the long line into which the instruction 
pair was to be placed. For example, the sequence 
K/:ABCDEFGH would have put the instructions 
ABCD and EFGH into the long line/;. The pur- 
pose of a warning character (K here) was to 
distinguish “meaningful sequences” from “inter- 
mediate rubbish” such as blank leader tape and 
erasures. This appears to be the origin of the term 
warning character, which appears frequendy in 
connection with early British software and re- 
appears in Strachey’s general-purpose macro- 
generator (1965). Once the complete routine had 
been read into the electronic store, a final mean- 
ingful sequence caused the routine to be written 
on the drum. In this way, each of the routines 
making up the programme was placed on the 
drum and finally the master routine was brought 
from the drum and entered. 

It would be difficult to imagine a more primi- 
tive input routine than this, in the sense that the 
conversions from the external symbolic form to 
the internal binary form were negligible; there 
was no provision for constants and there were no 
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142 assembly directives of any substance. Unfortu- 

nately, this rudimentary style of input routine was 
perpetuated on the production Mark I. 

There were several input routines for the pro- 
duction Mark I, each having its own PERM 'and 
sub-routine library. They are listed in Table 3. 
The reasons for this evolution can be summarized 
as follows: Scheme B arose as an improved ver- 
sion of Scheme A: TELEINPUT (or Scheme C) 
replaced Scheme B when a more reliable mag- 
netic drum was installed: and TELEIN PUT/F 
arose to make better use of the electronic store for 
certain classes of problem. 

The first input routine for the Mark I. Scheme 
A. was written by Turing and was available about 
March 1951. A complete listing of the input rou- 
tine has been located in the Strachey papers, and 
Section 3 of this paper shows its use for the devel- 
opment of a complete programme. 

Scheme A was essentially similar to the proto- 
tvpe input routine, although more flexibilitv was 
given by the provision of nine different warning 
characters instead of the three warning characters 
in the prototype scheme. Even so, Scheme A 
provided only the most basic facilities, and pro- 
gramme instructions were still written in tele- 
printer codes as described in Section 2.2. There 
was a provision for setting up integer constants, 
but there is no indication that this was much used; 
fractional constants had to be converted to base- 
32 with a Brunsviga calculator. The constant facil- 
itv was dropped from subsequent input routines. 

Scheme A consisted of four pages of code. 
Because of the generous provision of storage on 
tlie Mark I, there was no question of trying to 
compress the code into the minimum possible 
space: even so, it is disappointing that such a long 
routine did so little. For example, at Cambridge a 
much better input routine had been written in the 
equivalent of less than a page (Wheeler 1950). 

In mid- 1951 Glennie arrived from Cambridge, 
followed in July by Brooker. Very quickly 
Brooker, in consultation with Glennie, developed 
a new input routine known as Scheme B. This 
new routine was working in spring 1952 and 
ran in parallel with Scheme A. Unfortunately, it 
proved impractical to make a break with the 
teleprinter codes, and Scheme B was similar to 
Scheme A. Users had by now become too en- 
trenched in teleprinter notation to make a 
Annals of change. 

Compiling The main advanta ge over Scheme A was con- 
voi. 2. No 2 cerned with storing routines on the drum and 
April 19S0 calling them down to the electronic store for exe- 


Table 3. Mark I in 

put routines 

Input -cutine 

Date available 

Author 

Scheme A 

Spring 1951 

Turing 

Scheme B 

Spring 1952 

Brooker and Glennie 

TELEINPUT 
(Scheme C) 

Early 1953 

Brooker 

TELEiNPUT/F 

1954-1955 

Gillies 


cution. Because the magnetic drum had proved 
unreliable, the new input routine allowed rou- 
tines to be numbered serially and allocated actual 
tracks on the drum by means of a directory. Thus, 
if a programme could not be loaded because of 
faulty tracks, a new directory could be quickly 
prepared and no alteration to the programme 
proper was necessary. The serial numbering of 
the routines within a programme shows a strong 
connection with sub-routine assembly at Cam- 
bridge (Wilkes, Wheeler, Gill 1951, pp. 28-32), 
and the method of calling in a sub-routine, de- 
scribed in Section 2.5, shows similar connections. 
Incidentally, Scheme A did allow a directory to be 
used, but the implementation was much less ele- 
gant. Scheme B input occupied two pages of code, 
being more neatly coded than Scheme A. 

A new input routine called TELEINPUT, 
sometimes known as Scheme C, was devised by 
Brooker probably early in 1 953. The main change 
from Scheme B was that the directory, which had 
been obligatory in Scheme B, was now made op- 
tional. This reflected the improved magnetic store 
with fewer faulty tracks. It was still recom- 
mended. however, that programmes using more 
than six routines use a directory. 

TELEINPUT is the only input routine de- 
scribed in the third handbook, dated August 
1953. which seems to indicate that it had replaced 
Schemes A and B entirely by this date. A com- 
ment by Williams (1953, p. 37) seems to indicate 
that Scheme C and the sub-routine library were 
completed by about the end of the first quarter of 
1953 and that the programming system had at last 
stabilized. 

There was just one further input routine, 
F/TELEINPUT, by D. C. Gillies. F/TELEINPUT 
was an extended version of TELEINPUT that 
allowed routines to be relocated so as to occupy 
any page of the electronic store. It was mainly 
used for a limited set of problems where it was 
desired to keep more than one routine in the elec- 
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143 tronic store in order to reduce the drum transfer 

overheads spent in routing changing. F / 
TELEINPUT was probably written in 1954 or 
1955; it was not a replacement for TELEINPUT 
but was supplementary to it. 

2.5 Sub-routines 

The concept of the sub-routine was well known in 
all computing circles (see Annals, Vol. 2, No. 1, 
January 1980, pp. 7-36), but the details of imple- 
mentation varied considerably, depending largely 
on the constraints imposed by the computing 
machine — in particular, the quantity and speed of 
primary and secondary stores. 

The idea of breaking a problem down into a 
hierarchy of sub-routines also seems to have been 
commonly understood; in this respect, some of 
the ideas underlying structured programming 
are by no means unprecedented. Turing ex- 
pressed the idea as follows (HB1, p. 60): 

The sub-routines of any routine may themselves 
have sub-routines. This is like the case of the 
bigger and lesser fleas. I am not sure of the exact 
meaning the poet attached to the phrase “and so 
ad infinitum,” but am inclined to think that he 
meant there was no limit that one could assign to 
the length of a parasitic chain of fleas, rather than 
that he believed in infinitely long chains. This 
certainly is the case with sub-routines. One always 
eventually comes down to a routine without 
sub-routines. 

For the Mark I, a programme consisted of a 
master routine and a group of sub-routines. Nor- 
mally, each routine was contained in one or two 
pages and was located on an individual half track 
or full track of the drum. The programme began 
execution with the master routine in the first two 
pages of the electronic store. When a sub-routine 
was called, it was brought from the drum into the 
electronic store, overwriting the master routine. 
The sub-routine eventually terminated by bring- 
ing a fresh copy of the master routine and reen- 
tering at the instruction immediately following 
the sub-routine call. Of course, sub-routines could 
themselves have sub-routines, to any depth. 

When a routine was longer than two pages it 
was divided into pairs of pages, chapters, brought 
down one at a time and executed in sequence. 
This was essentially like calling a sub-routine, ex- 
cept that no return link was needed; this wa„ 
Annals of known as calling an “ad-routine.” 
the History of An interesting point of this arrangement was 
volTno^ that routines were necessarily confined to one or 
April 1980 two pages. Consequendy there was very little 


point, once a routine fitted within a page bound- 
ary, in reducing its size further (although con- 
siderable effort could be expended on trying to 
lose the two or three instructions by which the 
routine exceeded an exact page in size). This was 
very different in spirit to other installations where 
users delighted in writing programmes using as 
few instructions as possible. The drum store of 
the Mark I was so large that programmers, writ- 
ing in machine code, were never able to use more 
than a fraction of it for programme instructions. 

Turing’s method of routine changing on the 
prototype Mark I was based on a routine chang- 
ing sequence (RCS) of five instructions in PERM. 
Turing devised a similar method for the Scheme 
A input on the production Mark I, and this is now 
described. 

The basis of routine changing was the “cue.” A 
“true cue” consisted of a long line containing 
three items: the entry point of the roudne, a pair 
of check digits, and the magnetic instruction to 
bring down the routine to electronic store. A 
“false cue” was similar except that a directory was 
used to hold the true cue and the routine was 
called down via the directory; this involved an 
extra drum transfer to access the directory but 
enabled programmes to be run with an unreliable 
magnetic store. The directory technique was in- 
troduced as a result of difficulties using the proto- 
type Mark I magnetic drum. (The use of the term 
cue appears to be the origin of this term for a 
library sub-routine call in several early British 
programming systems.) 

Figure 4a shows how a sub-routine was called 
using scheme A. The call is based on a sequence 
of four calling instructions and two cues. The first 
cue is used by the RCS to bring down the sub- 
routine; the second is the link to return control to 
the calling routine. This routine calling method 
was unwieldy and suffered from two disadvan- 
tages. First, the user had to create a link to return 
to the sub-routine. Second, the user was responsi- 
ble for preserving the link in the sub-routine. If 
the sub-routine called further sub-routines, it was 
necessary for the user to make private arrange- 
ments to stack the links. 

Turing’s sub-routine linkage was a rather 
pedestrian piece of work for a person of his tal- 
ents. This is especially so when we consider that 
Turing had been aware of this idea of a sub- 
routine stack as early as 1945 (Carpenter and 
Doran 1977). Furthermore, Turing would surely 
have had access to a copy of the “Report on the 
Preparation of Programmes for the EDSAC and 
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the Use of the Library of Sub-routines” from 
Cambridge, which was circulated well before the 
end of 1950 and contained seminal ideas on the 
use and design of sub-roudnes. 

A much more elegant technique for sub- 
routine calling was devised by Brooker for use 
with Scheme B. An example is shown in Figure 4b. 
In this calling sequence, a return link is not explic- 
itly given but is fabricated by the RCS using the 
technique of the “Wheeler jump,” created by D. J. 
Wheeler at Cambridge (Wilkes, Wheeler, Gill 
1951). Similarly, there is no explicit cue for the 
sub-routine but simply a directory number that 
gives the location of the true cue in the directory; 
this had much in common with the technique of 
sub-routine assembly used at Cambridge. The re- 
turn link was automaucally placed on a stack main- 
tained by the RCS so that sub-routine calls could 


be nested to any depth and recursion was possi- 
ble. The sub-routine stack is clearly based on ear- 
lier Cambridge work (Brooker & Wheeler 1953). 

Parameter passing for sub-routines was re- 
stricted somewhat by the fact that a sub-routine 
overwrote the calling routine; this made it impos- 
sible to store parameters following the calling 
sequence, a technique favored at many installa- 
tions and pioneered at Cambridge. With Scheme 
A fractional parameters were placed in a specific 
store location for the sub-roudne to pick up; col- 
umn C seems to have been the most favored place. 
For integer and address parameters B-lines were 
usually used. With Scheme B, the accumulator 
was free to hold a single fracuonal parameter, and 
for sub-routines having a single argument and 
result this was sufficient; this in fact accounted for 
most sub-routines. 
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2.6 The Sub-routine Library 

When Cicely Popplewell arrived at Manchester in 
October 1949, her main task was to create a sub- 
routine library for the prototype Mark I. Unfor- 
tunately, little of this early work appears to have 
survived, although details of the library are given 
in the appendix to the first handbook. A total of 
ten sub-routines are named here; half were for 
input/output and half were mathematical func- 
uons. The only remnant of this work apparently 
surviving is a copy of a reciprocal square root 
routine attributed to Turing in the private papers 
of D. G. Prinz, dated November 1949. 

Litde of this work has survived, probably be- 
cause the sub-routines were not documented with 
anv great formality; after all, there were only four 
regular users of the machine. The sub-routine 
librarv for the prototype Mark I was never taken 
to a high degree of completeness because the ma- 
chine was operational for less than a year, and 
after a certain point it was futile to develop pol- 
ished routines for a machine that was soon to be 
replaced. 

The production Mark I was available in Febru- 
arv 1951 and the sub-routine library for Scheme 
A input was quickly started. The First sub-routines 
to be written were new versions of the sub-roudnes 
already prepared for the prototype Mark I. The 
sub-routines were rigorously documented in what 
Turing called the “official account,” which con- 
sisted of a pro forma, known as Programme Sheet 
1, explaining how to use the sub-routine and Pro- 
gramme Sheet 2 containing a list of the sub- 
routine. This style of documentation followed the 
Cambridge pattern used for EDSAC. Each sub- 
roudne was given a name intended to indicate its 
purpose — for example, DIVISION, LOGFAST, 
etc. Alternate versions of a routine were suffixed 
bv the letters A, B, C, etc.— thus DIVISION/A, 
for example. 

The Strachey papers contain what is probably 
an almost complete set of the Scheme A sub- 
roudnes. All the routines are dated, but the docu- 
mentation appears to have been done in bursts — 
the earliest sub-roudne being dated July 1951 and 
the latest September 1952. There are approxi- 
mately 50 sub-routines, which might be classified 
as follows: mathematical 14, input/output 13, and 
miscellaneous 23. The miscellaneous routines in- 
clude a number of sub-roudnes used in connec- 
uon with the “formal mode” described in Section 
2 . 7 ; they are clearly the work of Turing. 

The authors of sub-roudnes are not given in 
the official accounts, but a list of credits for the 


mathematical routines is given in the second 
handbook, where sub-routines are attributed to 
R. A. Brooker, A. E. Glennie, N. E. Hoskin, R. K. 
Livesley, C. M. Popplewell, and A. M. Turing. 
Sub-routines were placed in the library when sub- 
mitted by users and when it was felt they were of 
general use. Popplewell prepared the documenta- 
tion and was responsible for testing the routines. 

A second sub-routine library was prepared for 
Scheme B users in 1952. Where possible sub- 
routines were made compatible with both Scheme 
A and B, and this was achieved for at least half of 
them. The Strachey papers contain only a few of 
the early Scheme B sub-roudnes, presumably 
because he had by now left for Canada. Much of 
the Scheme B library would thus appear to be lost. 
The second handbook and its supplement indi- 
cate that there were about 20—30 sub-roudnes. In 
addition to the basic library of sub-roudnes, there 
was an excellent interpretive floating-point 
scheme, FLOATCODE. described in Section 4.1. 
Much of the sub-routine library was “exported” to 
the University of Toronto, where it formed the 
basis of the library for the FERUT, the second 
Ferranti Mark I (Godieb 1954, p. 125). 

A third sub-routine library was developed for 
Scheme C, but there was now a much clearer 
idea of exactly what sub-roudnes were needed. 
Brooker said (1956, p. 152): 

The number of library roudnes has been kept as 
small as possible by ruthlessly excluding roudnes of 
marginal utility. Thus, no attempt has been made 
to provide alternative versions in which, for 
example, emphasis is laid on time or space , 
economy measures. Instead, those that are 
available are described in detail, so that a user can 
modify it if he thinks this desirable. 

The third edition of the handbook contains 
what was presumably the complete set of 18 li- 
brary sub-roudnes as of September 1953, made 
up as follows: mathematical functions 6, input/ 
output 4, and floadng point 8. A compound li- 
brary tape contained the entire library and could 
be input to the drum in about half a minute. This 
was only possible because there was a fast paper- 
tape reader, a large backing store, and a very 
small library. Programmers generally used the 
compound tape rather than composing their own 
programme tape from the individual roudnes; 
this was a considerable convenience. In addition 
to the sub-routines, the library also contained a 
small number of complete programmes of gen- 
eral utility. These included programmes for ma- 
trix work, Runge-Kutta, quadrature, etc. 
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l4H A final picture of the sub-routine librarv. which 

grew considerably from the original 18 sub- 
routines, is given in the supplement to the third 
handbook (dated January 1956). This contains a 
large number of library routines, as follows (with 
their authors): print routines, Bessel functions (B. 
Richards); double-length routines, quadrature 
routines (C. M. Popplewell); complex functions 
(M. P. Hyde); matrix routines (F. H. Sumner); 
analytical differentiation (D. Morris). 

2.7 Turing and the Formal Mode 
One of the most interesting “finds” in this investi- 
gation into programming activity at Manchester 
was an elaborate protocol for running program- 
mes by Turing, which he called the “formal 
mode.” It would perhaps not be overstating the 
case to describe this as an operating svstem in 
embryo. 

The principle of the formal mode was to pro- 
vide well-defined interfaces between program- 
mer. machine, and operator. The first handbook 
(HB 1, p. 55) noted; 

The advantage of working in the formal mode is 
that the output recorded bv the printer gives a 
complete description of w hat was done in any 
computation. A scrutiny of this record, together 
with certain other documents!,] should tell one all 
that one wishes to know. In particular this record 
shows all the arbitrary choices made by the man in 
control of the machine, so that there is no question 
of trying to remember what was done at certain 
critical points. 

This rigid protocol seems strangely at variance 
with Turing s own methods of working, which 
tended to be unorthodox and unregimented. It 
seems likely that Turing may have been in- 
fluenced by his wartime experience at Bletchley 
Park. D. Michie (1978) writes that Turing’s 
formal mode is “strongly reminiscent of the kinds 
of routines and administrative operations we fol- 
lowed in the machine room . . . when the use of 
the COLOSSI was going on a regular shift basis." 
In fact, Turing probably picked up the opera- 
tional style for his formal mode in a different 
group than Michie's, but the regime would have 
been very similar. 

The heart of the formal mode of operation was 
a sub-routine called ACTION, which was the in- 
Annais ot terface between the programmer and operator at 
Computing ru "- time - The rule was that a programme would 
Voi. 2. NO. 2 only issue operator instructions by passing a mes- 
Aprii 1980 sage through ACTION; likewise, the operator 


would only respond to a message if it had been 
produced by ACTION. Such messages took the 
form 

+ + ACT ION message — 

After performing the action, usually loading a 
tape or setting the hand switches, the operator 
would restart the machine; ACTION would then 
print out the hand-switch setting, thus producing 
a record of the machine state at each step of the 
job. ACTION was a very short and simple routine 
(less than a page), and its sole function was to 
provide a formal channel for, and record of, com- 
munication between programme and operator. 
The original ACTION sub-routine has been lost, 
although there are later versions written in 1951 
and 1952 in the Strachey papers. 

Associated with the formal mode were a 
number of what we would now call “system rou- 
tines.” One of these, INTERFERE, enabled the 
operator to alter single lines in the store at the 
console, not unlike a present-day on-line debug- 
ging routine. Another more interesting routine 
was used with the “bursts" procedure. Because of 
the unreliability of the .Mark I, it was usual to 
perform any long computation in several bursts 
of a few minutes each; as an additional check on 
reliability, each burst was repeated until it gave 
the same result twice. The sub-routine BURSTS 
B formalized this arrangement so that a sub- 
routine could be performed repeatedly until con- 
sistent results were obtained, as determined by 
printing a check sum of the magnetic store. An 
associated routine COPY ROUT could be used to 
produce a reloadable dump of the magnetic store 
at the end of a burst; this is a very early example 
of a dump and restart procedure. 

Sadly, much of the ingenuity of the formal 
mode was wasted, because Turing was probably 
the only person who used it, and it was largely 
ignored by the other users. Two reasons can be 
identified for this. First, there was no operator for 
the Mark I at this time (even for Turing), so the 
formal mode was really something of an academic 
exercise. Second, programmers tended to debug 
and run programmes in a totally ad hoc manner, 
and the formal mode would have been a fussy and 
unnecessary barrier. Nevertheless, Turing made 
extensive use of the formal mode for his own 
programmes, and some examples of his pro- 
gramme output are in his papers at King’s Col- 
lege, Cambridge. Other aspects of the formal 
mode, such as conventions for preparing pro- 
gramme tapes, were bound up with Scheme A 
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147 input and were used by all programmers until 

Scheme B arrived. The following section illus- 
trates some of these aspects. 

3 A Tutorial on Programming the Mark I 

In order to illustrate the material in Section 2, this 
section develops a complete programme for the 
Mark I, as might have been done early in 1951 
when the production machine had just come into 
use. The programme is developed using Turing’s 
Scheme A and its associated sub-routine library. 

To provide a concrete example by way of illus- 
tration, a programme known as TPK has been 
prepared for this section, detailed in Figure 5. 
(An explanation of the TPK programme is given 
in the Appendix.) Figure 5 is primarily intended 
to convey the flavor of programming for the 
Mark I — for example, what the coding looked like 
and how the results would have appeared. Many 
readers, especially at a first reading, will wish to 
treat Figure 5 in this spirit. A deeper study of 
Figure 5 will reward the interested reader with a 
number of small but intriguing programming de- 
tails. The TPK programme has been tested on a 
simulator for the Mark I, so the coding and the 
results may be regarded as reliable. 

3.1 A Programme for the Mark I 
In the first handbook (HB1, p. 51) Turing de- 
fined programming as “an activity by which a 
digital computer is made to do a man’s will, by 
expressing this will suitably on punched tapes.” 
He itemized four stages of programming, used in 
the text below: 

1. Make a plan. 

2. Break the problem down. 

3. Do the programming of new sub-routines. 

4. Programme the main routine. 

Make a plan. 

This rather baffling piece of advice is often offered 

in identical words to the beginner in chess. 

Likewise the writer of a short story is advised to 

“think of a plot” or an inventor “to have an idea.” 

These things are not the kind that we try to make 

rules about (HB1, p. 61). 

For the most part planning the problem in- 
. volved doing the numerical analysis and scaling. 
The Mark I held fixed-point signed fractions in 
the range — 14s x < !4. Figure 5a shows the scaling 
Annals of calculation for the TPK programme that ensures 
the History of that all numbers stay within range. Scaling was 
Voi™^ U NcP 2 usually the most difficult part of planning a pro- 

Aprit 1980 gramme. For those who were less gifted nu- 


merically, and for small or one-off problems, 
floating-point routines were available to obviate 
the scaling problem at a cost of increased ex- 
ecution time. Machines such as the Mercury 
with hardware floating point were eventually 
developed. 

The next task is to plan the use of the store. 
There is little choice here but to follow the normal 
pattern for Scheme A: see Figure 5b. 

Break the problem doom. 

This in effect means to decide which parts of the 
problem should be made into definite sub-routines. 
The purpose of this is partly to make the problem 
easier to think about; the remaining work 
consisting of a number of “limited objective” 
problems (HB1, p. 63). 

Breaking the problem down thus consisted of 
dividing the programme into a master routine 
and sub-routines. So far as possible sub-routines 
would be taken from the library. In addition, any 
“auxiliary” sub-routines would be coded espe- 
cially for the programme. Figure 5c lists the rou- 
tines for TPK. 

Do the programming of the new routines. Turing 
advocated programming the sub-routines before 
the main programme — that is, bottom up instead 
of top down. This was mainly because it was gen- 
erally necessary to fix the details and scale factors 
of a sub-routine before a higher-level routine 
could be coded. 

Figure 5 d shows the coding for TPK. It is prob- 
ably just about feasible to follow the detailed cod- 
ing from the information in this paper, but not 
very profitable. It should be possible, however, to 
follow the general flow from the accompanying 
comments, which are intended to be in a format 
similar to that used on actual programmes. Notes 
have been added to explain some of the finer 
Joints of programming for the Mark I. 

Programmes were normally coded directly onto 
coding sheets. The coding sheets consisted of 
quarter-inch-squared paper overprinted with the 
teleprinter sequence arranged in the two columns 
making up a single page routine. Some of the 
details of annotation (for example, underlining 
unconditional transfer-of-control instructions) 
and the style of comments followed the pattern 
used on the EDSAC at Cambridge. When the pro- 
gramme was punched, however, only the instruc- 
tions themselves were transcribed. 

The text continues on page 152 , after completion of Figure 5. 
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in the TPK algorithm for each element f in the vector we 
have to calculate 


y = VTFF + 5t 3 


( 1 ) 


if we assume f is less than about 10 in magnitude then 
we can rewrite equation l as 


y' = 2-' 3 V 2 If' I + 5f' 3 


( 2 ) 


where/' = 2-« y and f = 2 -*'t. Now all numbers are 
less than one half in magnitude. 


(a) Scaling calculation 



Pages 

Contents 

SO. SI 

S2. S7 col K 
S4 col Vz 

S7 col C 

ROUTINES 

PERM 

VECTOR (systematic working 
space) 

VARIABLES and SUB-ROUTINE 
PARAMETERS (unsystematic 
working space) 

(b) Storage organization 


Routine 

Description 

MASTER 

AUXILIARY 

INPUT/A 

DEC-OUTPUT 

RECIPROOT 

Corresponds to the main body of the 
TPK algorithm 

Corresponds to the procedure f in 
TPK 

Library routine, reads a vector 

Library routine, prints a fraction 
Library routine, reciprocal square 
root 

(c) Table of routines 

Notes to Figure 5d, master routine 


The master routine occupies 2 pages, of which approximately 
1 14-pages are used. No attempt has been made to economize 
on the space taken. 


’The original TPK algorithm uses a tor-loop to read the vector 
There was a library routine. INPUT/A, to read a vector' 
however, so it is used here. 

3 Cycles around the main loop by setting B. to 20 and reducinq 
by two each time around the loop until it gets to zero The 
B-lme will also be used to access the array elements stored in 
long lines— hence the decrement of two. 

5 There was no sub-routine to print an integer, so some 
awkward scaling operations are used here to adjust the 
number for output as a fraction. 


Column / 


B 6 = H 3 / 2 - pointer 
plant cue 


set parms 
[for 

DEC-OUTPUT 



read array 
values using 
INPUT/A' 


call 

DEC-OUTPUT 


print Vz ■ B< 
using 

DEC-OUTPUT 3 


Icall AUXILIARY 
[using TC ... 


Figure 5. TPK for the Mark 1. 


"The routine INPUT/A only accepts values in the ranqe 
“ X < Vi«0 the data had to be scaled by 1 0- ! (for example 
0.099 was used for 9.9). Hence the scale factor of 100-2~‘ 
rather than 2 _s . 

‘This is the only instruction in the master routine that uses 
modification. It picks up the next element of the vector. 
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( d ) Programme — master routine 

6 The hoot stop causes the hooter to be pulsed each time 
around the two-instruction cycle. This gave a continuous note 
until the machine was stopped. 

7 Most of the constants were obtained from an appendix in the 
second handbook, attributed to the FERUT group. Powers of- 
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entry 2 


link 


DEC-OUTPUT 
entry 1 


AUXILIARY 


link 


two, used at several points in the programme, are obtained 
from PERM. 

8 DEC-OUTPUT has two entries. Entry number two is used for 
positive fractions and suppresses the sign. 


Figure 5 continues overleaf. 
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call 

RECIPRCOT 
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using 
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A' = 5t' 3 
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plant link 
enter RCS 
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closure 3 
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link 
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Notes to Figure 5d, auxiliary sub-routine 

The auxiliary sub-routine occupies one page. It evaluates (2) 
using location TC for the argument t' and the result y'. 

1 Because AUXILIARY uses a sub-routine we have to preserve 
the return link somewhere safe. 

2 RECIPRCOT is Turing’s combined reciprocal and square root 
sub-routine. By calculating the reciprocal of the square root, 
both reciprocal and square root could be formed by the 
relations 

(1/VNMI/VN) = 1/N and N-(1/vN) = VN 

To give maximum accuracy the result is "standardized" (i.e., 
the most significant digit is a one). The destandardization, and 
formation of reciprocal or square root, is achieved by a special 
piece of code given in the official account. 

3 To return to the master, we have to restore and plant the link, 
and then enter the RCS. 

4 There was a convention that local working storage in a routine 
was filled with the word USED, as a kind of comment. 
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(d) Programme — auxiliary sub-routine 


Figure 5 continued. 
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® 


® 


specimen punching (see note) 
..blank leader tape 
/ QHTPKAUXIUARYONEROUGH 
’/p\ KAK@/IIVzEIEZ 

Vi 1 K/’/2TVCTATCTK...TC/F 

KJVzJ IEJEJ IT: . . .1 III 
K/D'/2USEDUSED...E/EZ 
KVS@//////A/Y 
^^'blank trailer tape 

title sequence 
destination sequence 

punching proper 

final sequence 




KVS@££CA//EZ plant cue for master 
7 enter RCS 


number 

tape 


++INITIAL — 

QDDIRECTORY 

QRINPUT/AONE 

QNDECOUTPUTONE 

QNRECIPROOTONE 

QNRECIPROOTTWC 

QHTPKAUXIUARYONEROUGH 

QZTPKMASTERONEROUGH 

QZTPKMASTERTWOROUGH 

10 +0000004472 

09 +0000003162 

08 +0099900000 

07 -0004485585 

06 +0004775414 

05 +0099900000 

04 +0006235157 

03 +0099900000 

02 -010775505C 

01 +0099900000 

00 +0001809974 

L 

Ldecimal point 


. (e) Makeup of programme tape 

Note to Figure 5e 

In addition to the punching, there were various warning characters and special 
sequences: the title sequence labels the tape 'TPKAUXIUARYONEROUGH.' 1 the 
destination sequence associates the routine with an entry in the directory, the punch- 
ing proper causes the routine to be assembled in the electronic store, and the final 
sequence transfers the routine to a half-track of the magnetic store. The directory and 
master routine would be punched similarly. 


( f ) Printed output 
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Figure? 6. A general view of the Ferranti Mark I at Manchester University. Logic cabinets are to the left and right 
of the picture, and the control desk is in the center. The figure standing is A. M. Turing. 


tI Punc ^ l fS and Running routine. Using the reperforator, the various rou- 

he next job would be to punch the master and tines were usually duplicated to produce a single 
auxiliary routines and directory. For Scheme A, continuous programme tape. Library routines 

there were two types of routine tapes — rough were then rewound and returned. In fact this was 

tapes and writing tapes. A rough tape was the first not essential, and an alternative was to input 

form in which a routine was punched prior to the individual tapes one at a time. Handling so 

testing. Once a routine had been checked, a utility many individual tapes wasted time and could be a 
could be used to punch a writing tape. The writ- source of errors, however, so composite tapes 

mg tape was a cleaned-up version of the rough were usually used. Figure be shows the makeup of 

tape and included a check sum. Library routines a complete programme tape for TPK. 
and production programmes were kept in the Figure 6 shows a general view of the Mark I 
form of writing tapes. machine room. The machine was normally 

Rough and writing tapes were key features of booked for at least an hour. To run the pro- 

the formal mode of use. Rough tapes for routines gramme, the programme tape was placed in the 

were punched in a rigid format, and Figure be reader. For Scheme A the hand switches were 

includes^ the punching of one routine as an ex- reset, store cleared, and the machine started; this 

ample. Tapes were blind punched on one of brought down a starter routine that heralded 

two keyboard perforators, programmers usually its arrival by printing ++INITIAL (see Fig- 

punching their own tapes. ure of). As each routine was input, the titling se- 

Annais of Sub-routine tapes were kept in small boxes in a quence was copied onto the teleprinter, thus 

Computing °* Se . °j St ° rage drawers. The lowest drawer con- producing a printed record of the input process, 

voi 2. No 2 tamed the master copies, punched on blue tape. Input for TPK would have taken about one-half 

April i960 There was one routine tape for each page of the minute. 
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Figure 7. The two large (6-inch) monitor tubes displayed any two tubes in the electronic store on 
the Mark I console. The four 3-inch tubes above monitored the accumulator, B-lines, and control 
registers. The hand switches could be used to patch programmes during debugging. The paper- 
tape punch and reader are to the left of the console, and the teleprinter is on the right. 


Figure 8. The Mark I 
monitor tube displayed the 
two pages held in a Williams 
tube. The store lines are 
divided into five-bit groups 
corresponding to the tele- 
printer characters in the 
written form of the pro- 
gramme. The code displayed 
in this instance is the 
Scheme A PERM resident in 
page 4 of the electronic 
store. The 65th line, top left, 
indicates the drum track 
from which the pages were 
obtained. 


Annals of 
the History of 
Computing 
Vol. 2. No. 2 
April 1980 
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154 The programme would then be automatically 

entered, Figure of shows the printed results. Pro- 
gramme execution would have taken about a 
further half minute, the whole job taking a little 
over one minute in all. Finally, the programme 
would terminate on a "hoot” stop (a programme 
loop containing a hoot instruction; this produced 
a continuous note "about middle C” signaling the 
end of the programme). Incidentally, the loud- 
ness of hooting could be set by a volume control. 
Popplewell recalls that hoot stops went out of 
fashion when a new user ran a programme that 
terminated on a hoot stop, with the volume full 
on. He looked for a switch to turn off the hooter 
and the only one that seemed possible was labeled 
HT. Unfortunately it was the high-tension power 
supply; the machine took several days to repair! 

3.3 Programme Checking 

Programmes rarely worked the first time they 
were tried — even by the best programmers. 
Strachey (1966) expressed this rather well: 

Although we are happy to pay lip service to the 
adage that to err is human, most of us like to make 
a small private reservation about our own 
performance on special occasions when we really 
try. It is somewhat deflating to be shown publicly 
and incontrovertiblv by a machine that even when 
we do try, we in fact make just as many mistakes as 
other people. If your pride cannot recover from 
this blow, you will never make a programmer. 

Debugging was not a term in use in the early 
1950s in Britain, where the practice was known as 
programme checking. Figure 7 shows the console of 
the Mark I. which had exceptionally good moni- 
toring facilities and aids for programme checking. 
These included a pair of 6-inch monitor tubes 
that enabled any two tubes in the electronic store 
to be displayed. Figure 8 shows a close-up of one 
of the monitor tubes. The ease with which moni- 
tor tubes could be used with CRT storage was a 
very attractive feature of this technology; there is 
no equivalent for today’s memories. 

By sitting at the console, the programmer 
could observe the progress of the programme 
on the monitor tubes in a process known as "peep- 
ing.” Peeping was very much the modus operandi 
at Manchester; this attitude was very different 
from that at Cambridge where the practice was 
strongly discouraged as being wasteful of ma- 
Annais of chine time. This was one of the most significant 
Computing 01 d'ff erences between computing at Manchester 
Voi. 2 °No 9 2 anc * Cambridge: at Manchester the machine and 
April i960 its operations were very much geared to on-line 


programme checking, whereas at Cambridge 
the operating regime encouraged correcting 
“blunders” well away from the machine. It was 
some years before Manchester had a machine 
operator. 

Turing advocated the use of “checksheets” in 
association with peeping. The principle of check- 
sheets was that before running a programme, 
the author would dry-run the programme, en- 
tering on a checksheet the anticipated contents 
of the accumulator and relevant store lines as 
each instruction was obeyed. Programme testing 
then simply consisted of “single prepulsing” 
through the programme and comparing the ac- 
tual with the predicted behavior. Once a mistake 
was found, a correction could be inserted there 
and then, or the programmer could finish and 
ponder the error at leisure. Checksheets were 
a laborious way of testing a programme, and 
Turing was the main exponent of this particular 
technique, although other programmers used 
them on occasion. 

Besides single prepulsing, a programme could 
be monitored at full speed, although the execu- 
tion rate of about 850 instructions per second was 
too fast to follow the programme in detail. An 
interesting innovation was a third alternative by 
which instructions were obeyed at the rate of 50 
per second. A characteristic of the CRT store was 
that as an instruction or operand was fetched the 
corresponding line on the monitor momentarily 
brightened: thus, working in “slow-motion” 
mode, a programme loop, for example, could be 
observed as a bright band repeatedly moving 
down the page. 

The Mark I had two “optional stop” instruc- 
tions that could be made operative by setting ! 

either or both of a pair of console switches. When 
a programme had been fully developed the stops 
were disabled and the programme would run at 
full speed. The use of stops enabled checked-out 
parts of a program to be run at full speed: a stop 
placed at the beginning of a critical section then 
enabled it to be checked instruction by instruc- 
tion. The routine changing sequence contained a 
stop instruction so that the machine could be 
made to pause after each routine change, allow- 
ing tested routines to be run at full speed and new 
routines monitored. 

A device occasionally used was to place hoot 
instructions at strategic points in the programme. 

This produced a musical sound indicating when 
one part of the programme had finished and an- 
other part started — and also when something 
went wrong. The sound of a programme could be 
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155 quite pleasant and Prinz (1978), for example, re- 

calls once being congratulated on the musicality 
of one of his programmes. 

Checking routines of the type pioneered on the 
EDSAC at Cambridge (Gill 1951) were little used 
at Manchester for two reasons. First, the powerful 
monitoring facilities made peeping a more attrac- 
tive alternative. Second, the use of checking rou- 
tines interfered with the conventions concerning 
the use of the electronic store. An interpretive 
checking routine (trace routine) by Glennie 
printed out the function code letter of each in- 
struction as it was obeyed, but this routine (de- 
veloped in September 1951) was shortly made 
obsolete by the “development switch” added in 
1952. The development switch produced an auto- 
matic listing of the function letter of each order as 
it was obeyed; this could be switched on or off at 
the discretion of the operator. The D-switch was 
not often used, in fact, because the information it 
vielded was not particularly useful; the really 
difficult errors were those concerned with numer- 
ically incorrect answers (Brooker 1956, p. 154). 
The second handbook contains an interpretive 
checking routine that provided numerical trace 
information, but again it was probably little used. 

Postmortem routines were also little used at 
Manchester. The reason for this is that there was 
no redundancy in the order code. Consequently, 
if a programme went wrong and control was 
transferred to lines containing data, the machine 
would grind on remorselessly obeying nonsense 
instructions. An even worse feature was that 
empty words caused the hand switches to be 
obeyed as a magnetic instruction; this could result 
in the input routine being brought down to the 
electronic store, overwriting the original routine 
in the process, unless the hand switches had been 
carefully reset before entering the programme. 

It is interesting that once the practice of checking 
by peeping had become established — and the con- 
sole and programming system had been designed 
with this in mind, of course — there was little 
chance that alternative methods could compete. 

4 Simplifying Programming 

Programming the Mark I was no simple matter, 
and a good deal of effort went into trying to make 
things easier for the programmer. Three major 
difficulties were associated with programming the 
Mark I: 

Annals of 

the History of i. Scaling. It is difficult today to appreciate 
grffi that probably the biggest problem facing pro- 
Aprii 1980 grammers in the early 1950s was scaling numbers 


so as to achieve acceptable precision from a 
fixed-point machine. In big programmes there 
could be several different scale factors in order to 
maintain precision at different stages of the com- 
putation. Brooker recalls that whether machines 
should have floating-point hardware or not was 
probably the issue in computing circles in the early 
1950s. But until suitable hardware came along, 
floating point had to be programmed. 

2 .The two-level store. A real difficulty with the 
Mark I was organizing the flow of information 
between the magnetic and electronic stores. This 
was not too difficult for programmes, because 
they naturally tended to break into a hierarchy of 
routines. But for data the problem could be quite 
severe; for example, matrices had to be parti- 
tioned into page-size chunks and brought down 
one piece at a time. 

3. The language difficulty. Programmes written 
in the teleprinter code were difficult to write and 
even worse to understand. Because there was no 
relocation or symbolic addressing, programme 
corrections tended to be done by out-of-line cod- 
ing, which was always a potential source of trou- 
ble. As Glennie put it (19525, p. 2): “It is quite 
difficult to decipher coded programmes even with 
notes and even if you yourself made the pro- 
gramme several months ago.” 

In this section we examine the three most 
significant attempts to overcome these problems: 
FLOATCODE and the autocodes of Glennie and 
Brooker. In each case TPK will be coded for the 
system. Original listings of FLOATCODE and 
Brooker’s autocode have been located and used 
on the Mark I simulator, so the versions of TPK 
given are working programmes. Unfortunately, 
this has not been possible for Glennie’s autocode. 

4.1 An Interpretive Floating-Point Scheme 
Probably the earliest interpretive floating-point 
scheme for the Mark I was by D. G. Prinz of Fer- 
ranti, an external user. The scheme was devel- 
oped during 1951 and was described at the 
1952 National Computer Conference, Toronto 
(Bennett et al. 1952). This scheme was apparently 
used only by the Ferranti group. 

The most useful, and used, interpretive float- 
ing-point scheme was FLOATCODE by Brooker, 
which ran under Scheme B. The official accounts 
of FLOATCODE are dated July 1952, and a full 
description is given in the second handbook. The 
basis of FLOATCODE was a generalized inter- 
pretive routine called INTERCODE, which could 
be used as the nucleus of any interpretive scheme, 
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although in fact it does not appear to have ever 
been used for any other scheme than FLOAT- 
CODE. INTERCODE was essentially a switchbox 
that decoded interpretive instructions and trans- 
ferred control to various entry points in the main 
interpretive routine. 

Figure 9a shows the storage layout for FLOAT- 
CODE. The interpretive scheme was perma- 
nently resident in four pages. Two pages were 
given over to the user routine and two pages to 
working space. Figure 9 b shows the coding for the 
TPK programme. Interpretive instructions were 
written in the same format as normal instructions 
and were input by the normal input routine, the 
onlv difference being that the interpretive in- 
structions were obeyed by FLOATCODE rather 
than by the control circuits of the computer. It 
was possible, and necessary, to mix normal and 
interpretive instructions. The printed output 
from the programme is shown in Figure 9c. 

Floating-point arithmetic was slow compared to 
normal fixed-point operations; for example, ad- 
dition took 90 ms compared to 1.3 ms. On the 
other hand, a large part of any programme was 
concerned with organizational instructions, drum 
transfers, and input/output, which were un- 
affected by interpretation. Further, most of the 
floating-point library routines, such as square 
root, were written in normal instructions and 
were just as fast as the fixed-point equivalents. For 
most problems the speed penalty would have 
been no more than a factor of ten, and often less. 
The Mark I simulator indicated a factor of about 
two for the TPK programme. 

FLOATCODE shows very clearly its origins in 
the floating-decimal scheme Brooker developed 


with Wheeler (1953) at Cambridge shortly before 
arriving at Manchester. Much of the terminology 
and organizational details are the same, although 
the implementation is much more polished in the 
Manchester scheme. 

FLOATCODE was quite heavily used for jobs 
where speed of execution was of secondary im- 
portance, and Popplewell recalls that it was one of 
the really useful routines. FLOATCODE seems to 
have been eclipsed in 1953 when Scheme B was 
replaced by Scheme C. For Scheme C a new set of 
floating-point routines was provided. Although 
the new scheme was sometimes described as inter- 
pretive, this was not in fact the case. Operations 
were effected by a series of calls on a set of closed 
routines and there was no interpretive code as 
such. Although this was much less elegant than 
FLOATCODE, this was of little importance; with 
the arrival of the Mark I Autocode in 1954 
floating point was generally done via the autocode 
rather than directly. 

4.2 An Experiment in Automatic Coding 
In 1952 Glennie devised an automatic coding 
system to try to alleviate the language difficulty of 
programming the Mark I. Glennie called the sys- 
tem AUTOCODE; 6 this appears to be the origin 
of the term, which was widely used in Britain in 


"In general, the spelling AUTOCODE, used by Glennie, and 
Autocode, used by Brooker, will be adopted when referring to 
their respective systems. The generic term for all such systems 
will be autocode, which follows the normal usage in the early 
literature. 

The text continues on page 159, after completion of Figure 9. 
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Figure 9. TPK in 
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Column / 
/ II QO 
E E I / P 


enter FLOATCODE 1 

E E 1 1 P T 999 in /F 

@ / / / V read constants 2 400 in @F 

5 in : F 

A / / / V read array* 

: : / / £ leave FLOATCODE 3 

S UEHO B 4 = 20 
I S E / : 1 

new line 


U I E / 
’/2 / / T 


%E 

H 

B 

1 S 

/ 

C 

Vz E 

/ 

N 

@C 

/ 

E 

F / 

£ 

O 

E 1 

/ 

P 

1 / 

/ 

V 

T / 

Q 

O ■ 

E 1 

/ 

p 

/ C 

/ 

Y ' 

/ N 


w 

Vzl 

/ 

V 

@C 

/ 

Y ' 

@C 

/ 

w 

@F 

/ 

H 

* / 

/ 

M 

/ C 

/ 

Y 

@C 

/ 

W 

X / 

1 

” 

/ C 

1 

Y 

/ F 

1 

W 

@1 

1 

V 

£ 7 

1 

£ 


reenter FLOATCODE 


: '(A)=ai 4 


copy y into @C 


jF'(A) =y 
branch 
I F'(A) =999 


* into column N, lines /N . . . HN 


Column E 


A : HG B 4 = B 4 — 2 
: E / T branch to 1/ if B„ ; 


E E / V 
@E / P 


hoot stop 


Sill control number 
/ / L / carriage return 
/ / W/ linefeed 
Hill 20 


I I I I 
I I I I 


temporary storage 


Notes to Figure 9b 

1 The master routine starts in noninterpretive mode; the first two 
instructions call FLOATCODE, so the following lines are 
obeyed interpretively. 

1 it was possible to set up floating-point programme constants, 
but much easier to read them in from a data tape. The 
“instruction" ///V is an interpretive one to call the read vector 
routine; FLOATCODE looked after the oetails of linkage. 
’Here we leave FLOATCODE so that ordinary instructions can 
be used for organizational parts of the programme and 
nonfloating operations. 

4 Interpretive instructions could use B-lines in the normal way. 
The notation F(A) means the (pseudo) floating-point 
accumulator. 

5 The auxiliary sub-routine is written entirely in interpretive 
instructions. Routines could use normal or interpretive 
instructions, or a mixture. 


(6) Programme — master routine 


Figure 9 continues overleaf. 
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Figure 9 continued. 

Column / 

1/ @C / Y 

copy t into ffiC 

j E @ C / W J 

: @ @/ / M F' (A) = (t| 

j A : / / V F'(A) = v'|t| using FC:SQUAREROOT 

j : : C / Y save in :C 

is @C / G 

1 1 @C / Q 

’ll fflC / Y 

! 

: Vfe[ @C / Q 
i D j @ C / Y 

;R | : F / G 
; J j @ C / Q 
i N | : C / W 

If | / u/ £ 

(c) Programme — auxiliary routine 


+ 10 . 

+ 4.4721 

3195 

-02 

+ 9 . 

i - 3.1 622 

7815 

-02 

+ 8 . 

+ 9.9899 

9998 

+02 

+ 7 . 

- 4.4855 

8620 

+01 

+ 6 . 

— 4.7754 

1374 

+01 

+ 5 . 

+ 9.9899 

9998 

+02 

+ 4 . 

+ 6.2351 

5750 

+01 

+ 3 . 

+ 9.9899 

9998 

+02 

+ 2 . 

- 1.0775 

5050 

+03 

+ 1 . 

+ 9.9899 

9998 

+02 

+ 0 . 

+ 1.8099 

7447 

+01 


(d) Printed output 


the 1950s and early 1960s. Let us illustrate the 
technical aspects of AUTOCODE by showing how 
TPK would have been coded. 



scaling calculation; this is shown in Figure 106. 
Figure 10c shows the coding for TPK; several 
footnotes have been added to explain some of the 
more obscure points in using AUTOCODE, but 
even a cursorv study of Figure 10 will convey the 
flavor of AUTOCODE. 

Perhaps the feature of AUTOCODE that 
strikes one first is how extremely machine depen- 
dent it was. No attempt whatever was made to 
conceal the machine architecture. In many re- 
spects AUTOCODE had more in common with a 
present-day high-level assembler (for example, 
see Wirth 1968) than with a programming lan- 
guage. Certainly it did nothing to make pro- 
gramming easier for a novice, who would need to 
be very familiar with machine code programming 
to use AUTOCODE in the first place. Glennie 
claimed (1952a) that the system enabled an ex- 
perienced programmer to write programmes 
much more quickly, with fewer errors, and that 
the resulting inefficiency was no more than about 
10 %. 

The language itself has. for its period, some 
very attractive features. The assignment state- 
ment, for example, shows a finelyjudged balance 
between object code efficiency on one hand and 
programmer convenience on the other. The 
LOOP-REPEAT statement shows equally sound 
judgment. (Incidentally, in the first draft of the 
user's manual, this was SUM-REPEAT, indicating 
that a process of refinement and generalization 
was goingon.) Glennie (1959. p. 29) has described 
the business of designing a language: 

In my experience, notations for automatic codes 
are constructed by a process of introspecuon on 
the part of the inventor, who writes down possible 
notations and then tries to analyse how he himself 
recognizes them for what they are and which are 
the significant words. He seeks to put himself in 
the posiuon of a teacher teaching a very backward 
child how to read. 


AUTOCODE programmes were blind punched 
4.2.1 Technical details. AUTOCODE was inti- using the normal keyboard perforators. Much of 

mately tied to the normal Scheme B routine the written form of the autocoded programme 

changing sequence and the sub-routine library, was notional rather than actual. For example, 

so the problem would be broken into routines in there was no distinction between upper- and' 

the usual way. Figure 10a shows the routines for lowercase letters, subscripts were not dropped to 

the problem; the library routines are taken from a lower line, and there were no layout characters, 

the normal Scheme B library. AUTOCODE al- It was not possible to list a programme, 

lowed routines to be numbered 1, 2, 3, etc., ac- The translator occupied 10 pages of code and 
Annals ol cording to their position in a standard Scheme B contained some 750 instructions: of these about 

computing 01 c *‘ rectoI 7’ w bich would have to be prepared by 140 instructions were used for the translation of 

voi. 2 . No. 2 t f le programmer. AUTOCODE did not address arithmetic expressions (Glennie 19526). AUTO- 

Aptii 1980 the problem of scaling so we have to do the usual CODE did not produce diagnostics as such but it 
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1. INPUT/A input vector 

2. DECOUTPUT/A print accumulator as ±M*L 

3. SQUAREROOT 

4. AUXILIARY 

5. MASTER 

(a) List of routines 


a@/%- b@VA c@MA d@GA e@OA f@Z: y@PA’ 
FRACTIONS +49999 -» b +00004 -► d +0000999 -> e 2 

SUBROUTINE 1 
LOOP 10n 4 
n -* c 5 

+bc SUBROUTINE 2 
+a n SUBROUTINE 4-» y 6 
+y-d TESTA X 7 

+y SUBROUTINE 2 CONTROL Y 8 

ENTRY X +e SUBROUTINE 2 

ENTRY Y REPEAT n 

ENTRY Z CONTROL Z 9 

WRITE 5 START 5 10 

(r) Programme — master routine 
Notes to master routine 

’Fractional scalars and vectors are identified by a single 
letter. Variables have to be allocated actual storage locations; 
thus b is at line VA, c is at line MA, and so on. The vector a is 
placed in systematic work space in column Vz-. The variable f 
is assigned to line Z: of PERM, which contains the value / 16// 
we will need later; this has to be done in this way because it 
was not possible to set up integer constants. 

2 The FRACTIONS statement fills variables with initial values, 
which must be in the range -Vz-< x < Vz-. Thus 0.49999 in b, 
0.00004 in d, and so on (we really wanted 0.5 in b but this 
would be out of range so 0.49999 is used). 

3 Six integer variables were denoted by k, I, n, o, q, and r, 
corresponding to six of the B-lines, which were used for count- 
ing and array subscripts. This statement sets q (B 6 ) to the value 
in f (/%//) which in fact is a pointer to the vector stored in 
column Vz. Next, SUBROUTINE 1 is called to input a vector 
using the parameter B 6 to the point to the vector. 

4 The statement pair LOOP lOn . . . REPEAT n causes the inter- 
vening statements to be obeyed repeatedly. The index n is 
initialized to 20 (i.e., twice 10) and decremented by 2 each 
time around the loop until it gets to zero. 

5 The effect of this line and the next is to multiply the index by 
a half and print it using sub-routine 2. 

6 We now load a n into the accumulator and call the auxiliary 
sub-routine. The accumulator is used for the argument and 


We have to calculate for each element t of the vector 

y = VTtl + a 3 (i) 

Assuming that t is less than about 10 in magnitude we 
can rewrite equation 1 as 

y' = 2 -13 V 2 IN + 0-5f' 3 (2) 

where y' = 10 -7 y and t' =10 -2 f. Now all the numbers 
handled are less than a half in magnitude. Notice that 
scaling has been done in powers of 10 rather than in 
powers of 2: this is because AUTOCODE allowed 
decimal constants to be used (so perhaps there was at 
least a little help with the scaling problem). 

( b ) Scaling calculation 


b@VA c@MA d@GA e@OA t^a/C 1 
FRACTIONS +49999 b +000001 e 
t 2 

+t TESTA X 
-t 

ENTRY X SUBROUTINE 3 c 3 

+tt — > d +td d +bd — » d 4 

+ec+d 5 

CLOSE 6 

WRITE 4 

( c ) Programme — auxiliary sub-routine 
result. The result is stored in y when we return from the sub- 
routine. 

7 TESTA X transfers to the point labeled ENTRY X if the accu- 
mulator 5= 0. 

9 y is printed using sub-routine 2. CONTROL Y is an uncondi- 
tional transfer of control. 

9 The programme terminates on a "dynamic stop." 

10 This line is a directive to write the master routine to the 
magnetic store as routine number 5, and then enter it 
Notes to auxiliary sub-routine 

1 Variables and initial values are assigned in the usual way in 
the first two lines. Note that t has been put in column C; it is not 
stored locally like the other variables because when the 
square-root routine is brought down later it would be de- 
stroyed. 

2 The argument is transferred to AUXILIARY via the accumula- 
tor, so we save it in t and set the accumulator to Itl. 

3 Sub-routine 3 forms the square root of the accumulator, which 
we save in c. 

“These statements form 0-St 3 . It was not possible to have terms 
containing more than two operands; this was a limitation im- 
posed for efficiency reasons to make the best use of the Mark 
I instruction set. 

5 This leaves 10 -6 \/Tt] + 0-5t 3 in the accumulator. 

6 CLOSE returns to the master routine."" 


Figure 10. TPK in Glennie’s AUTOCODE. 
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160 would come to a stop if it detected a syntax error. 

The point where the programme tape halted in 
the reader then gave the location of the faulty 
statement. 

AUTOCODE was very fast and, programme 
for programme, was about as fast as the normal 
input routine. This was partly because autocoded 
programmes used many fewer symbols. For this 
reason, programmes were never stored in binary 
but were translated each time they were used. 
Probably TPK would have taken well under a 
minute to translate. (This contrasts startlingly 
with contemporary American automatic coding 
systems, such as the UN I VAC A-series compilers, 
which would have taken much longer. 7 (Inciden- 
tally, all the Manchester University machines have 
tended to use fast load-and-go compilers, and 
such things as linkage editors and object code are 
not part of the Manchester tradition.) 

4.2.2 Historical details. Until Knuth and Trabb 
Pardo’s recent paper (1976), very little was known 
of Glennie’s work. Glennie himself never pub- 
lished an account of AUTOCODE, although a 
few brief comments were published to the effect 
that there was an automatic coding system in 
existence. 8 Glennie never published partly be- 
cause it was not usual for scientists in the employ 
of the Ministry of Supply to publish their work — 
and Glennie was engaged in highly classified nu- 
clear weapons research. In any case, not being in 
the academic community, Glennie had little need 
for publications to make his reputation. Glennie 
also recalls that he found it difficult to compose a 
paper in the accepted scientific style that would 
have appealed to a learned journal. 

Glennie’s recollection is that the idea of auto- 
matic coding was very much in the air in the early 
1950s. It was well known that Aiken had con- 
structed a special-purpose coding machine for the 
Harvard Mark III (Harvard 1952). It was equally 
well known that there was “no need to build a 
special machine for coding, since the computer 
itself being general purpose should be used for 
coding” (Glennie 19525). 

AUTOCODE was designed for the specific pur- 
pose of reducing the drudgery of coding and 
hence the incidence of programming errors. Of 
all the early Mark I users, Glennie probably had 
by far the biggest problems to solve, so that for 


the History of ' See. f°r example. UNI VAC (1956), where compilation times 
Computing ’ of about 10 minutes are typical. 

Vol. 2. No. 2 "See. for example. Strachev (1952), Bennett and Glennie 
April 1980 (1953), Mutch and Gill (1953). 


him the burden of programming in teleprint code 
was most acute. In the atmosphere of a university 
laboratory, one was prepared to try radical 
approaches and Glennie undertook the develop- 
ment of AUTOCODE in the spirit of an interest- 
ing sideline to his proper work. 

AUTOCODE was written during about three 
months of part-time activity in the summer of 
1952; in September it was described by Strachey 
(1952) as “just coming into use.” Unfortunately, 
Glennie destroyed the original tapes and listings 
of AUTOCODE many years ago. However, he 
did prepare two drafts of a user’s manual for 
AUTOCODE that give a detailed account of its 
use (Glennie 1952 a). 

Shortly after AUTOCODE came into use, 
Glennie was invited by M. V. Wilkes to speak on 
the subject at one of the Cambridge seminars. 
Fortunately, Glennie’s employers had a strict rule 
that staff members intending to publish or lecture 
externally first had to submit the proposed dis- 
sertation (in triplicate) for security clearance. 
Glennie prepared typed lecture notes (Glennie 
19525) for the seminar that contain a detailed ac- 
count of the internal structure of the translator 
and the nature of the code generated. Glennie 
gave his seminar in February 1953; by and large 
it was well received, although its impact in making 
people do things differently was very small. 

In the early 1950s the use of automauc coding 
was very far from being universally accepted. For 
example, Gill was rather disparaging about the 
value of Glennie's work in the discussion follow- 
ing the Cambridge seminar and he repeated these 
remarks almost word for word at the NPL sym- 
posium in March 1953. Glennie (1977) recalls tell- 
ing Turing about AUTOCODE. At first Turing 
was quite interested, until he realized that Glennie 
had achieved formula translation rather than 
formula manipulation; “then the shutters came 
down, it just wasn’t up to his intellectual stan- 
dard.” On the other hand Strachey (1952) was 
much more enthusiastic and announced it as “a 
first and very important step.” (Incidentally, the 
Strachey papers contain notes for an automatic 
coding scheme entitled “Generalised Program- 
ming" with some notational similariues to 
Glennie’s AUTOCODE. These notes are undated 
but would seem to be roughly contemporary with 
AUTOCODE.) 

AUTOCODE was in fact only used by Glennie 
himself. Probably he could have done much more 
to sell AUTOCODE to other users but his posi- 
tion as an external user no doubt made him reti- 
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161 cent. Glennie did use AUTOCODE for several The Autocode TPK programme has been run 

problems of his own, so the development was not on the Mark I simulator and the printed output is 

without some benefit. The problems solved each shown in Figure 1 15. It was not possible to lay out 

had about 100-300 statements. Soon after this, the results in the form of a table because the print- 

Glennie became involved full time with a much ing of a number is invariably accompanied by a 

larger problem for which AUTOCODE was inap- new line. These rather rudimentary output facili- 

propriate, and so it died a natural death. ties were probably not a serious handicap for the 

Glennie (1965-1967) has described AUTO- kinds of problem run using Autocode, which 

CODE as “a successful but premature experi- tended to be small one-off jobs, 
ment.” The reasons that AUTOCODE had so lit- The following description of Autocode is based 
tie impact bear some examination for the insight on a written account given in the supplement to 
they give into what factors made for a successful the third handbook (HB3S), which includes a 
automatic programming system in the early complete listing of Autocode. In addition, 

1950s. The most serious shortcoming of AUTO- Brooker’s original coding sheets for Autocode are 

CODE was that it did not address the problems of still in existence, and these have been used to re- 
scaling or of the two-level store. There was little solve certain ambiguities. Figure 1 lc shows the 

incentive to use AUTOCODE when the pro- store layout of an Autocoded programme. Auto- 

grammer was still left to deal with scaling, which code was based on the standard Scheme C 

was by far the most difficult part of program- floating-point routines, which were kept perma- 

ming. Furthermore, AUTOCODE was incapable nently in the electronic store. The programme 

of tackling problems that required use of the itself was translated into a chain of routines that 

magnetic store for holding arrays of data (such as were stored on consecutive tracks of the drum, 

matrix problems). An important feature of any During execution, the programme was brought 

automatic coding system was the extent to which down two pages at a time, transfers of control 

it could be readily used by inexperienced users; between pages being completely taken care of by 

AUTOCODE signally failed in this respect. Per- Autocode. 

haps the final lesson is that to be a success, an The storage management of floating-point 

autocode needs committed full-time program- variables was perhaps the most significant feature 

ming support; Glennie could not provide this. of Autocode. The several thousand floating-point 

variables were stored on consecutive tracks of the 
4.3 The Mark 1 Autocode drum. Whenever a variable was accessed, the 

In 1954, Brooker introduced a system of auto- MAG. LOCATION routine computed the drum 

matic coding specifically designed to enable address of the variable and brought the relevant 

nonexpert users to run small problems. The sys- track into the electronic store. Appropriate mea- 

tem, at first called “the simple machine” and later sures were taken to avoid bringing a page down 

the “Mark I Autocode,” attacked simultaneously again once it was already in the electronic store, 

all three problems facing the Mark I pro- Similarly, pages that had not been altered were 

grammer: scaling, the two-level store, and the not written back to the drum. Brooker called this 

language difficulty. Let us first see how the TPK concept the “one-level” store. Some of the basic 

programme would have been coded in the Mark features of a page-changing algorithm for virtual 

I Autocode. storage can be seen in embryo. 

The Autocode translator took about 2 minutes 
4.3.1 Technical details. The Mark I Autocode to load from paper tape, but this only had to be 

was a very polished system. The TPK programme done once for a batch of programmes. The corn- 

shown Tn Figure I la 9 is all that a programmer piling speed was about 2 seconds per instruction, 

would need to prepare; there were no complica- and the execution speed about 6 instructions per 

tions such as selecting library routines or punch- second. The TPK programme would have taken 

ing directories. Autocode programmes were about 1 00 seconds: 40 seconds to translate and 60 

punched on teleprinters especially acquired for seconds to execute. (Execution would, of course, 

the Autocode service, and a listing of the pro- have taken longer if the variables had not all been 

Anna i s of gramme was automatically produced. stored in the same page.) In general programmes 

the History oi __ ran between five and fifty times slower than equiv- 

Voi 2. No 9 2 “This TPK programme is essentially the same as in Knuth and alent machine code programmes. The code 

April 1980 Trabb Pardo (1976, p. 64) with the correction of a small error. generated by Autocode was very crude, mainly 
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2 


4 

5 


nl = 1 
vnl = I 
nl = nl + 1 
j3, 1 1 nl 
nl = 11 

* n2 = nl - 1 
v12 = F6(vn1) 
v12 = F1(v12) 
v13 = 5®vn1 
v13 = vn1®v13 
v13 = vn1®v13 
v12 = v12 + v13 

j4, v12 > 400 

* v12 = v12 

j5 

' v12 = 999 
nl = nl - 1 
j2, nl > 0 
H 
(jl) 


inputs a;' 

tests for last cycle 

prints i a 
v12 = Vla] 4 

v13 = 5a, 36 

y = VH + 5a, 3 

prints y 

prints 999 

tests for last cycle 
halts 

starts programme 7 


cycle 11 times 2 


cycle 11 times 2 


(rz) Programme 

Notes to Figure 7 7a 


+ 10 . 

- +.04472 
+9. 

+.03162 

+ 8 . 

+999. 

+7. 

-44.85586 

+ 6 . 

+47.75413 

+5. 

+999. 

+4. 

+62.35157 

+3. 

+999. 

+ 2 . 

-1077.55051 

+1. 

+999. 

+. 

+18.09974 

(b) Printed output 


Floating-point variables were denoted vl. v2. v3, ...,up to 
about v5000; these could be used as scalars or vectors. In- 
teger variables, "indices," were denoted nl, n2 n18 and 

were used for counting operations and subscripts. For the TPK 
problem, the vector is stored in vl to vl 1. 

' I cn the right-hand side of an "equation" caused the next 
value to be read from the number tape. 

2 Programme loops were spelled out in full, there being no 
specific loop control statement. 'j3' means jump to the state- 
ment labeled 3. 

3 An asterisk (*) before an equation caused the result to be 
printed. This was very useful for debugging; once a pro- 


gramme was working, the *'s could be overpunched with an 
erase symbol. 

4 F6 and FI are the absolute value and square root functions, 
respectively. Function calls couid not be nested. 

5 There was no sub-routine facility, so the coding for a proce- 
dure has to be given in-line. 

‘ An arithmetic expression could be no more complicated than 
a single binary operation on two operands. Hence 5t s has to be 
calculated using several statements. 

7 Instructions in parentheses were obeyed immediately as an 
"interlude." This sequence is used to start the programme by 
jumping to label 1. 
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163 because there was nothing to be gained by pro- 

ducing efficient code. Even though only about 
five Autocode instructions were accommodated 
on each two-page track, there was still adequate 
room on the magnetic store for programmes of 
several hundred instructions. Further, efficiently 
generated code could do nothing to overcome the 
built-in inefficiency of floating point and the one- 
level store. 

Autocode gave no diagnostics at all and tended 
to digest anything it was given — erroneous pro- 
grammes produced erroneous results. For well- 
formed programmes Autocode generally 
behaved satisfactorily, however. Just one serious 
error has been found in the listings of Autocode; 
integer division is not performed. This is quite 
clearly a simple coding error, and presumably the 
surviving documentation does not reflect the fully 
debugged compiler, for such a gross error could 
not have lain dormant for very long. 

Autocode was a very big programme for its day. 
The code can be broken down as follows: 




Approx, no. of 


Pages 

instructions 

Translator 

36 

' 1800 

Floating-point routines 
Mathematical functions, 

6 

300 

I/O, Runge-Kutta, etc. 

16 

800 

Complex routines 

14 

700 

Total 

~T2 

3600 


Autocode included facilities for the solution of 
differential equations by Runge-Kutta and calcu- 
lations involving complex variables — reflecting 
the needs of the users. 


Annals of 
the History of 
Computing 
Vol. 2. No. 2 
April 1980 


43.2 Historical details. A first version of the 
Mark I Autocode was developed by Brooker early 
in 1954, and a paper describing the system was 
submitted in March (Brooker 1955). Livesley and 
Popplewell worked on the first application for an 
outside user in late 1954 (this was a small set of 
one-off calculations for a local mechanical engi- 
neering firm). In the summer of 1955, Brooker 
rewrote the entire Autocode system, and this ver- 
sion is described and listed in the supplement to 
the second handbook. Brooker’s original pro- 
gramme manuscripts are dated from May to 
August 1955. As well as some slight syntactical 
changes, the second version of Autocode included 
facilities for complex variables. 

Brooker was well aware of Glennie’s earlier 
AUTOCODE, of course, although he had not 
himself used it. But in fact the systems had no 


more in common than the name autocode and 
were completely separate developments. Inter- 
estingly, Brooker was reluctant to call his system 
“autocode” and first called it “the simple ma- 
chine.” In a contemporary letter to Strachey (late 
1954) Brooker wrote: “Incidentally I am coining 
the phrase Unicode for my autocode — mainly to 
avoid comparison with Glennie’s.” But “auto- 
code” rapidly came into the language as the Brit- 
ish equivalent of “programming language,” and 
Brooker doubtless acceded to fashion. 

With hindsight, we can see that the most 
significant innovation of the Mark I Autocode was 
the concept of the one-level store. Brooker recalls 
that this was a rare moment of inspiration; it just 
suddenly occurred to him that since there was 
already the inefficiency due to floating point, 
it would be worth the additional inefficiency of 
having a one-level store. The one-level store as 
implemented in the Mark I Autocode was one of 
the seminal ideas that achieved final expression in 
the virtual store of the Atlas. 

Considered as a programming language, rather 
than as a simplified means of using the Mark I, 
Brooker’s Autocode is less impressive. Certainly, 
the control structures and arithmetic expressions 
are not as well developed as in Glennie’s AUTO- 
CODE. To be fair, Brooker did not consider the 
design of a sophisticated programming language 
to be part of his brief; his aim was to devise a 
method of simplifying programming, particularly 
for inexperienced users. In this Brooker suc- 
ceeded admirably; as Gill put it (Lunt 1957): 

This work calls for a tremendous amount of 
experience and sympathy with the programmer 
who will eventually use the scheme and a number 
of attempts have failed because one or other factor 
was not taken into account. Dr. Brooker seems to 
be more capable than many people 1 know of 
choosing just the right combination of features to 
be included in a scheme of this kind. 

Gill in fact gave Brooker considerable help with 
promoting Autocode. 

The language of the Mark I Autocode was so 
simple that Brooker (1958, p. 16) subsequendy 
described it as “amounting to what is nothing 
more than a two- or three-address instruction 
code.” The simplicity of the language was instru- 
mental in getting it accepted by new users. (A very 
similar aim was much later embodied in BASIC.) 
The complete programmer’s description of Auto- 
code occupied just two sides of foolscap, with a 
third side to describe an example. Brooker spent 
a great deal of time polishing this “standard ac- 
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164 coun I L ’’ A surviving description of Autocode 

entitled 'The Standard Account of the Simple 
Machine” is dated June 1955.'“ With supplemen- 
tary sheets describing the use of the Run^e-Kutta 
function and complex variables, the documenta- 
tion grew to a total of nine sides. Autocode was so 
easy to teach and to learn that new users could be 
trained in a matter of hours. 

With the arrival of Autocode a small computing 
service was established, and a machine operator 
and a keypunch operator were hired at the Com- 
puting Machine Laboratory. The usage started at 
about one hour per day in 1954 and gradually 
built up to perhaps three or four hours per day 
Autocode produced a breakthrough in pro- 
gramming by reducing programming and testing 

kT-T a L ‘ P t0 3 f attor of one hund red (Richards 
K/J). A postal Autocode service was set up 
wherein users mailed their programme manu- 
scripts which were then punched and run with 
a usual turnaround time of less than a week 
hollowing its completion in 1955, some 12 hours 
of machine time per week was used for the 
Autocode postal service alone (Brooker 1958 
p. 16). The service was enthusiastically used 
bv the Central Instrument Laboratory of Im- 
perial Chemical Industries where G. E. Thomas 
now headed the computer section, assisted bv 
K. Richards, both formerly associated with the 
Mark I at Manchester. At ICI, courses were riven 
in Autocode and scientists developed thei^own 
programmes, typically for problems in chemical 
and statistical calculations (Thomas 
, 9/ 4-',° ther Users of the P ostal service included 
the Theoretical Physics Branch of the Atomic 
Energy Research Establishment at Harwell 
Autocode was a tremendous success, particu- 
larly with engineering users for whom time was 
money. Autocode enabled them to get pro- 
grammes working with unprecedented speed 
Brooker recalls being buttonholed one davbv a 
delighted user for whom Autocode had just saved 
several tens of thousands of pounds on a civil 
engineering contract. At a March 1957 meeting of 
the Society of I nstrument Technology, S. T Lunt 
from Id’s Central Instrument Laboratory, gave 
an account of the economic and other benefits of 
using Autocode in chemical engineering design 
(Lunt 1957). The meeting was a great success and 
did a lot to promote Autocode. Such was the en- 

me n S!lto!y Of thusiasm at the meetin S that Brooker found him- 

Computing - 
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self the man of the moment and was invited to 
dine with the inner circle of the society. Automatic 
coding had arrived. 

5 Assessment 

The Mark I was dearly a difficult machine to pro- 
gramme. but this is a judgment made in retro- 
spect: most contemporary users had nothing with 
which to compare it and consequently had little 
complaint. 

A notable feature of life in the Computing Ma- 
chine Laboratory was what might be called lack of 
management control— or to put it another way 
all chiefs and no Indians" (Glennie 1979) But 
this atmosphere gave a freedom to experiment in 
automatic coding systems that might not have 
otherwise developed. The Manchester autocodes 
evolved to simplify programming; indeed so suc- 
cessful was Brooker's Autocode in this respect 
that the Mark I became possibly the easiest ma- 
chine to programme in Britain. 


5.1 The Early Programming System 
Turing’s programming scheme for the proto- 
type Mark I was a prosaic piece of work. Given the 
exigencies of developing an input routine very 
quickly for a machine that was never destined to 
be a permanent fixture, this was understandable. 
Perpetuating an essentially similar scheme on the 
production Mark I was unfortunate, however. 
1 he arguments for programming directly in tele- 


printer code, largely based on correspondence 
between the written form and the monitor tube 
display, were insubstantial— and never came 
about at Cambridge, for example. It seems that 
1 uring did not recognize the importance of clear 
notation in programming: he himself had no 
difficulty and he did not expect others to. A re- 
mark by Wilkes (1968, p. 4) throws some light on 
1 unng’s attitude: 

He had a very nimble brain himself and saw no 
need to make concessions to those less 
well-endowed. I remember that he had decided— 
presumably because someone had shown him a 
train of pulses on an oscilloscope— that the proper 
way to write binary numbers was backwards with 
the least significant digit on the left. He would, on 
occasion, carry this over into decimal notation I 
well remember that once, during a lecture, when 
he was multiplying some decimal numbers together 
on the blackboard to illustrate a point about 
checking a program, we were all unable to follow 
his working until we realized that he had written 
the numbers backwards. I do not think that he was 
being funny, or trying to score off us; it was simply 
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165 t J] at f 1 ? could not appreciate that a trivial matter of 

that kind could affect anybody's understanding one 
way or the other. 

Even if the suggestion for a more suitable pro- 
gramming notation had been put to Turing, one 
feels he would have been unlikely to respond to it. 
It is clear that elegance or cleverness in pro- 
gramming was not a subject that interested 
Turing. The only exception to this was Turing’s 
“formal mode,” but even here the actual imple- 
mentation was awkward and unpolished and no 
doubt contributed to its lack of use. A recollection 
of Tootill’s (1978) sums up Turing’s attitude to 
programming: 

Turing looked on programming as boring routine 
work — he seemed in fact to regard tidying up a 
working program as a waste of time, like, for 
example, turning all the pennies in vour pocket the 
same way up. 

One of the hopes for Brooker’s appointment to 
the^ Computing Machine Laboratory, in October 
1951, was that he would improve matters for the 
users. The subsequent programming systems, 
Schemes B and C, were attempts to streamline 
the input process. That it was not possible to 
break with the teleprinter notation is an interest- 
ing example of what might be called the “inertia 
factor” that has dogged many software projects: 
namely, early design decisions, both good and 
bad, tend to be perpetuated. (An outstanding 
example of this is the FORTRAN' DO-loop— not 
to say the entire FORTRAN language.) It seems 
to be an almost superhuman endeavor to make a 
change and persuade others to follow. 

5.2 The Autocodes 

The primitive state of the programming system 
did have a valuable side effect in stimulating the 
development of automatic coding systems. This 
was quite different from the situation at Cam- 
bridge where the programming system developed 
by Wilkes and Wheeler was so satisfactory that 
much of the incentive for making improvements 
was removed. 

Glennie’s AUTOCODE was an outstanding in- 
novation. Jts failure to catch on had two main 
causes, first, it did not overcome the worst fea- 
tures of programming the Mark I (scaling and 
storage management), and second, it did not at- 
tract the support of the laboratory (perhaps a 

Annals of natural reticence on the part of Glennie had some 

the History of p art to pl ay h ere ). 

Computing 1 r-p, \ 

Voi. 2, No. 2 * rea ' success story of the programming ef- 

April 1980 fort was Brooker’s Mark I Autocode. The success 


of the Mark I Autocode (especially when con- 
trasted with Glennie’s) can be attributed to several 
factors: 

1. Ease of use. Autocode was easy to learn and 
use, it attracted a body of new users rather 
than trying to win over existing pro- 
grammers. 

2. Fulfilled a need. Autocode offered significant 
facilities not otherwise readily available 
(floating point, one-level storage, simplified 
input/output). 

3. Effective selling. Autocode was promoted by a 
series of programming courses, an excep- 
tionally short and comprehensible manual, 
and a postal service for remote users. 

4. Committed support. Autocode had the full sup- 
port and enthusiasm of the laboratory in 
terms of maintenance, documentation, pro- 
gramming advice, and consultancy. 

The above would make an effective checklist 
today for the launch of any new software product. 

Brooker s Mark I Autocode was probably the 
most significant programming innovation of the 
mid-1950s in Britain: it inspired several imitations 
at the time when American directions were not 
widely reported in Britain. For example, G. E. 
Felton, programming manager for the successful 
Ferranti Pegasus, initiated the Pegasus autocode, 
which was released in the summer of 1958 (Felton 
1978); from this grew the autocode for the Fer- 
ranti Sirius computer shortly after. Also in the 
late 1950s autocodes for the Elliot 802 and 803 
were produced. All these systems had an ex- 
tremely strong family resemblence to Brooker’s 
progenitor." Brooker’s Mark I Autocode, and his 
subsequent Mercury Autocode of 1958, was a 
dominant influence on British autocodes until 
well into the 1960s. It was only in the middle and 
late 1960s that ALGOL 60 and FORTRAN be- 
came a significant force for British computers. 

53 Conclusions 

Apart from the one bright spot of Brooker’s 
Mark I Autocode, it is dear that the place of the 
Manchester Mark I in the history of computer 
development is secured far more by its hardware 
than by its software. The Mark I had three bril- 
liant hardware innovations: the first operational 
CRT memory, the index register; and (albeit 

1 Burnett-Hall et al. (1964) describes several early British 
autocodes of this type. 
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166 somewhat unwittingly) embryonic virtual mem- 

ory hardware. The early software failed in any 
wav to match these triumphs. For example. W. G. 
Welchman, who had contemporary experience 
on both sides of the Atlantic, recalled (1979): 
When 1 returned to England in early 1954... I was 
appalled bv the contrast between what was going 
on in America in applications and programming 

and what I found in Manchester Ferranti were 

already offering, their Mark I computer in America 
in competition with the ERA 1 101. But the British 
engineers were very poorly supported by 
programmers [and] applications research. 

Significantly, the Mark I found no takers in 
North America. But Welchman'sjudgment is per- 
haps harsh; software generally played second 
fiddle to the hardware in early computers. Also, 
when it arrived in March 1954, Brooker’s Mark I 
Autocode would have stood comparison with any- 
thing developed in America; it is unfortunate that 
Ferranti failed to exploit it on Mark I* computers. 

Finally, it is appropriate to say a word about 
Turing's contribution to the work of the labora- 
tory. which thus far has appeared to be somewhat 
negative. Turing certainly made some positive 
contributions. For example, he was an accom- 
plished mathematician and often helped others in 
matters of analysis and numerical methods. On 
his own account, Turing was an indefatigable pro- 
grammer: he was probably the heaviest user 
of the Mark I (two whole nights every week) 
(Hodges 1979). It was during this period that he 
did much of his work on morphogenesis (Turing 
1952), which his death in June 1954 cut short. In 
those with whom he worked. Turing inspired awe 
and often affection. As Glennie recalled recently 
(1979): 

Turing's manner of thought was so different from 
most other people’s that his ideas both irritated 
and invigorated. You had to be mentally prepared 
for all sorts of unusual ideas where Turing was. 
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APPENDIX 


The TPK Algorithm shows the output from the program for a given 

In their report The Early Development of Pro- set of test data (when run on an ICL 1903 A 

gramming Languages (1976), Knuth and Trabb computer). The TPK algorithm demonstrates the 

Pardo argue that the best way to understand a following points: the use of variables, constants, 

programming language is to study specimen pro- and a vector; a program loop proceeding by posi- 

grams; this communicates the flavor of a lan- tive increments and another by negative incre- 

guage far more effectively and concisely than a ments; accessing successive vector elements; a 

lengthy programming manual. The authors in- conditional statement; built-in functions, such as 

troduce the TPK algorithm in their report. square root and absolute value; input/output pro- 

The TPK algorithm is a short program that cedures; a user-written procedure. The program 

demonstrates many of the characteristic features is quite short in duration and would probably 

of a program; by coding TPK in a variety of have taken between a few seconds and a couple of 

languages Trabb Pardo and Knuth have been minutes to run on a first-generation computer, 

able to contrast a number of historic pro- depending on how fast the computer was and 

gramming languages in a succinct yet informative how effective the language and its translator, 

fashion. Of course, TPK does not actually do anything 

A version of the TPK algorithm written in useful, but it would be difficult to devise a more 
ALGOL 60 is given in Figure Ala. Figure A lb illustrative program using fewer statements. 


begin integer i; real y; real array a[0: 10]; 
real procedure f(t); value t; real t; 

f := sqrt(abs(t))+5*t f3; 
for i := 0 step 1 until 10 do a[i] := read; 

for i : = 10 step -1 until 0 do 
begin newline(l); print(i,2,0); 
y := f(a[i]); 

if y > 400 then print(999,4,5) 
else print(y,4,5); 

end 

end of TPK algorithm; 


Annals of (a) ALGOL 60 program 

the History of 
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Test data: 1.5 8 -6 9.5 2.3 9.9 

2.1 - 2.1 6 0.001 - 0.002 


Printed output: 


0.04472 

0.03162 

999.00000 

-44.85586 

47.75414 

999.00000 

62.35158 

999.00000 

-1077.55051 

999.00000 

18.09974 


(ft) Test data and results 
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169 This paper is intended to correct the list of printed 

papers of Charles Babbage ( 1791—1871 ) that 
Babbage printed in the back of his partial 
autobiography , Passages from the Life of a 
Philosopher ( London , 1864). That list has been 
reprinted in several modern publications, but no 
attempt has been made to make it accurate or 
complete until this article. In an effort to make the 
list more useful to the reader , notes follow many 
of the items to explain their significance in 
Babbage’s life and work. 

No manuscript items are included; the paper 
deals only with Babbage’s list of printed works, as 
they existed at the time of his death. 

Keywords and phrases: Babbage, bibliography, 
publications, mathematics, Analytical Engine, 
Difference Engine 
CR category: 1.2 


Introduction 

"I have frequently had applications to write my 
life, both from my countrymen and from foreign- 
ers." wrote Charles Babbage in Passage from the 
Life of a Philosopher (1864, p. vii); "to many of 
these I sent a list of my works, with the remark 
that they formed the best life of an author.” 

Indeed they do, in large measure, when accu- 
rateiv listed and their significance at least partially 
explained. Unfortunately, Babbage's lists were 
not accurate, nor were they supplemented with 
anv explanation or description. This paper at- 
tempts to correct that situation and thereby assist 
the reader who wishes more fully to understand 
and appreciate this gifted and farsighted man. A 
few preliminary words are needed for the benefit 
of those who know little about Babbage, his life, 
and his work. 

Charles Babbage, the Man 
For the past 25 years or so, Charles Babbage has 
been known as a scientific pioneer whose work 
presaged the development of modem computer 
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technology. Many words of praise were written 
about Babbage after his death in 1871, but mod- 
ern evaluation of his work probably took hold in 
1953 with the publication of B. V. Bowden’s Faster 
Than Thought. 1 Calling Babbage “one of the most 
farsighted men of his generation,” Bowden went 
so far as to say: “he understood clearly ail the 
fundamental principles which are embodied in 
modern digital computers.” Speaking of the Ana- 
lytical Engine, tvhich was Babbage’s second major 
effort in calculating machines, Bowden described 
it as the “first universal digital computer, as the 
expression is understood today.” Bowden did not 
attempt to prove a direct connection between the 
Analytical Engine and the computer technology 
of the 1950s, and that issue is still debated today. 

Other writers have examined Babbage’s ma- 
chines in more detail. Philip Morrison and Emily 
Morrison (1961) drew heavily on Babbage’s own 
descriptions of his work and on a book by the 
inventor’s son, Henry P. Babbage, published in 
1889. Perhaps the most thorough study of Bab- 
bage’s engines is Bruce Collier’s unpublished 
Ph.D. thesis (1971), “The Little Engines That 
Could’ve.” 

Characteristically, Babbage did not carry 
through to conclusion any of his efforts on cal- 
culating engines. He worked 10 years on his first 
Difference Engine, which was designed to cal- 
culate and produce mathematical tables. As 
discussed in Collier’s dissertation, Babbage fre- 
quently enlarged his vision of what the machine 
could be made to do, which kept it in a constant 
state of redesign. There were mechanical prob- 
lems stemming from the state of the art in making 
machinery at that time. He also encountered con- 
siderable difficulty with support from the British 
government because of misunderstandings that 
are too complex to recount here. These delays 
and problems allowed him time to think of a 
whole new concept (the Analytical Engine), and 
he pursued the design of this concept off and on 
for the rest of his life. During the late 1840s, he 
worked for a while on another machine he called 
Difference Engine No. 2. All of these efforts, 
including his relations with government, are dis- 
cussed by the Morrisons and are summarized or 
glossed over lightly by several other authors. 2 
Anyone interested in the whole story should con- 



1 Bowden’s first chapter, “A Brief History of Computation,” 
includes a short life of Babbage (pp. 7-22). 

- See, for example, Bernstein (1964), Rosenberg (1969), and 
Halacv (1970). 


